“Map used with permission of the Bay Area Orienteering Club baoc.org“

Features

1. Outer-rim is a protractor that rotates just like oil-bath compass
2. Protractor can be locked, and stays locked
3. Compass needle responds to magnetic north
4. Day and night views
5. Designed to perform correctly in airplane mode (GPS disabled)
6. No cellular signal nor GPS signal required needed
7. Accurate rulers graduated with 2.5 inches and 6 cm (Based on iPhone @ 163 ppi)
8. No setting. Pick it up, it works

Since the Orienteering Compass performs equally well with or without Global Positioning System enabled, it can be used to simulate a physical protractor compass used under similar conditions. While it is not intended to be used during orienteering competitions, it certainly makes a great and realistic training apparatus.

Its minimalistic and intuitive interface makes it an ideal learning and teaching tool, complete with rotating protractor and glow-in-the-dark appearance.
Since it is designed primarily around the stringent needs of orienteering (accuracy, readability, no setup or preferences to fiddle with, protractor and rulers, no cellular signal), it makes it a perfect compass for outdoors activities such as backpacking, hiking and trekking. The simple fact that it runs in “Airplane Mode”  allows Orienteering Compass to be a low consumption, energy efficient application.

Hardware Requirements

1. An iPhone 4
2. or an iPhone 3Gs (with internal magnetometer)
3. or an iPad (any version) Note that the rulers are not accurate on iPad

(Not to worry, you will not be able to buy this application from the App Store if your device does not have an internal magnetometer.)

About the Compasses…

1. Familiar Interface

All protractors’ outer rims rotate the same way.
Use the outer rim to adjust, and a single lock button to fix.

A lock prevents the compass-heading information from drifting.
The heading can be set once, and will stick until changed. Quitting the application will not affect the heading. Just like an oil-bath compass, only one heading is stored at a time.

2. Different looks

Regular protractor ; Large and Off-centered ; Night ; Nautical.
Day, twilight and night (low light screen).

The protractor lines in the Nautical style make it easy to adjust the heading using an iPhone. After all, the iPhone is not transparent and the practical layout makes it a useful tool.

Headings are remembered across all compasses styles.

The night-look interface featured here is particularly dim and readable in low-light situations.

3. A tool, not a toy

Simplicity has not been sacrificed to the interface

While most compass applications give the geographic (true) and magnetic north, the approach to Orienteering compass is to make it a straight substitution for a physical device. Where others may have created eye-candy, most of the time relying on the GPS for current coordinates and even links to actual maps (using precious battery power in the field), Orienteering Compass is explicitly replicates the simple and elegant oil-bath compass.

4. Rulers, Direction Of Travel and other features

Rulers

All iPhones (and iPod Touch) come with a screen resolution of 320×480 pixels at 163 ppi. This means that, when measured vertically or horizontally, exactly 163 pixels will fit in a linear inch. Using this characteristic, Orienteering Compass is able to provide two different rulers, one 2.5 inches long on one side, and one 6 cm long on the other.

DOT

The Direction Of Travel is clearly marked by an arrow on all screens.

Independent Outer-Rim and lock

The outer-rim rotates and locks independently of the compass needle. Once locked, it is not at risk of being accidentally changed. The application can also be safely exited, the setting of the outer rim is not affected.

Airplane Mode

Orienteering Compass does not rely on the GPS nor the cellular signal to calculate it’s orientation. It relies upon the internal magnetometer embedded in the iPhone 4, 3Gs and the iPad. If you are using Orienteering Compass in an outdoor setting where a source of power may not be readily available, it is recommended to put your phone in Airplane Mode to conserve battery. As a matter of fact, Orienteering Compass will work in an airplane!

How to use…

“Map used with permission of the Bay Area Orienteering Club baoc.org“

1. Align the Direction Of Travel

Put the device on top of the map.
Align the course to the side of the phone. It matters not to align the current position with the rulers. Only the direction of travel matters.

2. Adjust the outer-ring

Unlock the outer-rim.
Align the protractor with the magnetic north of the map. There is no need to orient the map, since the protractor rotates freely. Make sure you use the maps’s magnetic north, or compensate for local declination. Orienteering maps indicate the magnetic north. When set, tap “lock”. Note that the rim would lock on it’s own after a short delay.

3. Orient the compass

Rotate the device until the needle and the protractor overlap.
When the compass needle and the protractor overlap, the DOT arrow (the front of the phone when held flat) points to the direction of travel.

Get it now.

Orienteering Compass is available on the App Store.

Click here to visit Orienteering Compass on the App Store.

(http://itunes.apple.com/us/app/orienteering-compass/id372749402?mt=8)

Technical Support

• orienteeringcompass@thegothicparty.com

End-User License Agreement (EULA)

No guaranties, implicit or explicit.
The complete End-User License Agreement can be read at:

thegothicparty.com/dev/wp-content/extras/orienteering-compass-EULA.html

Bookmark this on Delicious

Features

1. Magnetic north, to suit the traditional behavior of good old compasses
2. Compass moves independently of background
3. 4 compasses to choose from, using the i button.
   

Hardware Requirements

1. iPhone 4
2. or iPhone 3Gs (with internal compass)
3. or an iPad (any version)

(Not to worry, you will not be able to buy this application from the App Store if your device does not have an internal magnetometer.)

About the Compasses…

1. E. L. Holmes

Master Compass, a navigating apparatus.

Inspired by an apparatus patented by Edward L. Holmes on February 1, 1926. Patent No 1,702,405.

…Fig. 1 shows schematically the several units comprising the master-compass and a repeater-compass illustrative of mechanism which may be actuated and  controlled by said master-compass – together with a wiring diagram of an electrical system which may be employed in connection therewith; …

A single drawing from E. L. Holmes has been carefully and faithfully reproduced, to bring this invention to life in Old Compass. The only modification added for convenience and use as a compass is the addition of three typewriter characters indicating west, south and east, not present in the original graphic.

2. J. Schiessler

Sound-Indicator for Vessels.
An apparatus patented by Josef Schiessler on October 18, 1904. Patent No 772,676.

…The principal object of the invention is to indicate the direction of movement or the approach of a vessel not yet seen, maybe at night or in a fog. … The apparatus consists of two main parts, one of which is arranged on the deck of ship, whereas the other is submerged into the water and connected with the other main part by means of a tube …

While not actually a compass in the original J. Schiessler invention, the device has as similar needle pointer in the author’s drawings. The device comes to like in Old Compass, as the magnetic heading is indicated by the floating arrow.

3. T. Dawson

Navigational mariner’s compass, composed of two systems.

By the end of the sixteenth century, several features of the compass were established conventions: the image of the rose at the axis ; the eight-pointed star ; the points of the compass such as “north by north-east” ; the Fleur de Lys indicating north ; the Cross indicating east; four quadrants of 90 degrees each ; and sometimes a sundial. This compass rose has it all, including the sundial which the mariner could use to tell the time as well as heading. The sundial’s marking were designed to be used on the northern hemisphere.

You too can use the Old Compass to tell time from the secondary dial using the sun’s position, or find the geographical north independently of the compass position when knowing the local time.

As published in “The Seaman’s Secrets”, Thomas Dawson, 1607. First appeared in a 1596 document.
National Library of Canada

The image (or other media file) is in the public domain because its copyright has expired.

4. J. Aguiar

A 32-point compass rose
From a nautical chart drawn by Jorge de Aguiar. This is apparently the oldest personally signed Portuguese nautical chart, dated 1492.

Original is in the Beinecke Library, Yale University, USA.

The image (or other media file) is in the public domain because its copyright has expired.

The rose hovers over the map.

Get it now.

Old Compass is available on the App Store.

Click here to visit Old Compass on the App Store.
(http://itunes.apple.com/us/app/old-compass/id370131301?mt=8)

Technical Support

• oldcompass@thegothicparty.com

End-User License Agreement (EULA)

No guaranties, implicit or explicit.
The complete End-User License Agreement can be read at:

thegothicparty.com/dev/wp-content/extras/oldcompass-EULA.html

Old Compass iPhone App On The Web…

Old Compass iPhone App (Vieille Boussole appli) is featured on
Chasses-aux-trésor.com.

Bookmark this on Delicious

This site is really a hybrid of out-of-the-box WordPress, and the following:

1. Customized stylesheets
2. Home brew Template theme file
3. Movies & Audio plug-ins
4. A CSS animation (on the home page)
5. GraphicConverter automatic web-page feature
6. Word to HTML feature

When I take an airplane, I cannot help but think of all the poor programming practices I have witnessed -some committed by myself- over the years. I often wonder if the on-board computers have been programmed by my earlier engineering peers.

1. A short Object Oriented Programming Refresher

1.1 Object Inheritance

Say you have three classes. An airplane, a commercial airliner and a private jet. We can all agree that both the jet and the airliner are kinds of airplanes.

This is the basis of object-oriented development. You model abstract objects after entities in the real world.

1.2. Object Properties

Say that an airplane has landing gear, I reckon all airplanes have landing gear. Assuming we are not discussing here the very specific case of hydroplanes, the gear (at least a generic one) should probably belong to the airplane object.

1.3. Inherited Properties

So in the real world, having landing gear is not particularly specific to the private jet or the commercial airliner. Being fitted with landing gear, retractable or not, is general to all airplanes.

1.4. Class Members

The landing gear, in itself, can be a pretty complex device.

1. Member variables

   It has members that remember states, such as stowed away vs. ready for landing.
   Example: isReady

2. Member methods

   It also has functions, which generally, but not always, will change its state. Such functions can be deploy vs. stow.

   Example: Deploy()

This is where encapsulating functionality into an object starts to make a lot of sense. You need not to know the specifics of how a mechanism (or an algorithm) is implemented. You only need to know how to invoke it: in this example, it’s Deploy().

1.5. Delegate Behavior

In this simplified model, it matters not which kind of airplane you fly. All you need to do is to flip a switch to initiate the landing procedure, and the airplane object just “knows” what to do.

1.6. Larger Picture

2. A Programming Error Crash Course: Dont’ fly with those!

I have gathered below a few errors I have seen in the past. Do not try this at home!

2.1. public static


BAD:
// Whenever needed
if( nil == Airplane.staticLandingGear) {
    Airplane.staticLandingGear = create an instance of LandingGear
}

... followed somewhere upon destruction of the object:

// Upon desctruction of the creator
if( nil != Airplane.staticLandingGear) {
    delete Airplane.staticLandingGear;
    Airplane.staticLandingGear = nil;
}


While this may look proper at first glance, and possibly even work depending on the situation, I have seen this code create havoc when placed in the “Private Jet” or “Commercial Airliner” sub-class. Create more than one plane and you have a disaster.

BETTER:
// Whenever needed
aLandingGear = Airplane.getLandingGear();

getLandingGear()
{
    // Ensures only one LandingGear instance exists
    if( nil == staticLandingGear) {
        staticLandingGear = create a unique instance of LandingGear
    }
    return staticLandingGear;
}

1. Problem:

   More than one object may destroy the public static variable

2. Suggestion:

   Use a singleton and a private static.

2.2. silent error

BAD:
if( nil != aLandingGear) {
    aLandingGear.Deploy();
}

Defensive programming has it’s price. In this case, the software will not crash if the LandingGear object does not exist. Good.
Conversely, the plane will crash because no landing gear has been deployed. Bad.
This situation could have been detected early on if the software had not failed silently during the development phase, before it was deployed.

BETTER:
assert( aLandingGear); // Will alert QA that something went terribly wrong
if( nil != aLandingGear) {
    aLandingGear.Deploy();
} else {
    // Something is terribly wrong and we should not be there
    startEmergencyProcedure();
}

1. Problem:

   Failure goes undetected and unreported during development

2. Suggestion:

   Use assert() and error_log() to report unexpected conditions

2.3. uninitialized object

For this example, assume that the landing gear needs to be connected to an airplane.

BAD:
if( ! aLandingGear) {
    aLandingGear = new LandingGear();
}
// The app will not crash, because aLandingGear exists
aLandingGear->Deploy(); // Will do nothing. Plane will crash!


If an object MUST be initialized, one possibility is to make the default constructor private

BETTER:
if( ! aLandingGear) {
    aLandingGear = new LandingGear( anAirplane);
}


1. Problem:

   Failure to initialize an object

2. Suggestion:

   Make constructor private to force the use of proper initializer, otherwise source code will not compile in the first place.

2.4. A bug? Which bug? I didn’t see a bug.

I will conclude with my favorite quote from an engineer with whom I do not share the view. I can see the benefits and even possibly some logic behind it, but this is why I hate to fly.

If a bug cannot occur, it is not a bug.

W.W.

I guess that I am not inclined to take the risk; a condition could have been overlooked, or simply created at a later maintenance stage. New situations will arise as the software evolves, and code that was once safe may be misunderstood and misused. From the same engineer, I’ve also heard this:

W.W.

No comment.

Bookmark this on Delicious

Instruments has built-in tools to isolate true leaks (lost blocks) but can also be used to locate memory loss. While this session references iPhone OS 3.1.3, it can be generalized: only the example is specific, not the concept.

…as an engineer, I tend to differ: if every time I invoked a library API, I’d loose roughly 1 megabyte of RAM, I’d soon be running out of memory. I will also argue that, since this memory “cache” is neither documented nor explicitly reported it is, for all purposes, a leak(*).

(*) A leak is a lost block. But not all lost blocks qualify as leaks. This article focuses on the ones that don’t. Just like leaks, these lost blocks are consuming memory space. That space is generally not reclaimed until the host application quits.

1. Launch Instruments

From XCode, launch your application using “Object Allocations”
For this tutorial, we are not using Leaks Instrument Template. While Leaks is very effective against true leaks, it is oblivious to retained but forgotten objects, over-retained objects, or poor API implementation.

2. Run your application

In this example, only 32 seconds (about 0.54 minutes in Instruments notation) were needed to expose the unexpected memory usage.

It is a good idea to be generous in early scoping of memory usage, since it will fluctuate. For the purpose of this tutorial, this preliminary analysis phase has been skipped entirely.

3. Stop the Application execution

It has been established during other sessions that the particular memory consumption we are studying does not change during the lifetime of this application. Stopping it after 34 seconds.

Instruments can start/stop/save/restore sessions, which makes it invaluable to compare the program behavior before/after alterations.

4. Objects Created and Still Living

Focus on the objects that have been allocated, but not de-allocated.

Obviously, objects created but no longer living have been de-allocated, and are not of particular interest while searching for leaks.

5. Observe the Object Allocation Graph

Looking at the graph, it is easy to spot sudden memory allocation. For increased granularity, reduce the “Inspection Range”.

The Inspection Range will reduce the number of items present in the Diagram View below.

6. Set the View mode to Diagram View

7. Navigate the Diagram View

This is a very handy feature of Instruments. By sliding or dragging the time line cursor, the Diagram View selection will scroll accordingly. By bringing the triangular cursor precisely over the edge of the sharp raise of memory usage around the 0.54 min (32.5 seconds) area, one discovers pages and pages of a repeated call to -[NSDateFormatter getObjectValue:forString:range:error:]

8. Focus on the Diagram View

Observing the Diagram View, sorted either by “Responsible Caller” or by “Creation Time”, one can see the repeated invocation to the same NSDateFormatter method.

9. Call Stack

Turn on the call stack view (Extended Detail View)

10. Final analysis

By selecting a single line in the Diagram View, and inspecting the corresponding call stack in the Extended Detail View, one can focus on a single invocation and, hopefully, isolate the code responsible for the memory allocation. A double-click will jump to the source code, if available.

For example, +[Manager dateFromString] is the method responsible for invoking the suspicious NSDateFormatter -dateFromString selector.

Two facts will attract our attention:

1. There are pages upon pages of NSDateFormatter invocations, all grouped together when sorted by Responsible Caller.
2. When sorted by Creation Time, about 8000 invocations to NSDateFormatter take place within the same 100 ms.

When looked at closely, this study lead to a decision to not use NSDateFormatter time zones, which turned out to be the culprit.

11. Related links

• NSFormatter memory leak
• Wikipedia article about memory leak

Bookmark this on Delicious

I ran into the same situation, with very similar leak sizes to the ones reported on that article. Instruments shows that 868 Kb (889520 bytes to be exact) are allocated by Cocoa on iPhone OS (verified from 2.x to 3.x up to 3.1.3).

1. Z Offending Code

The objective of this method is to convert a string into a date.
Note that I do invoke -release on the NSDateFormatter object, and that the newly created NSDate is destroyed when the NSAutoreleasePool is drained. This is not where the problem lies.

NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
[dateFormatter setTimeZone:[ NSTimeZone timeZoneWithName:@"GMT"]];
[dateFormatter setDateFormat:@"EEE, d MMM yyyy HH:mm:ss z"];
[dateFormatter setLenient:YES];
{
    NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
    NSDate *testDate = [dateFormatter dateFromString:string]; // <- Allocates 868 Kb
    // Do something with testDate
    [pool drain];
}
[dateFormatter release];


2. Discussion

It appears that this is caused by the z option in setDateFormat.
My guess is that Cocoa allocates exactly 8618 time-zone related objects that live in memory for the duration of the application.
I do not know of any workaround, other than not using the “z” option.
[ dateFormatter setDateFormat:@"EEE, d MMM yyyy HH:mm:ss"];

3. Instruments log

Here is the allocation log for the first 3 of the 8618 objects, allocated all at once by a single invocation to dateFromString. Without going into too much details, suffice it to say that I used “Created & Still Living” option in “Allocation Lifespan”, and that the “Extended Detail” view in Instruments shows that all those objects are created back to back as the result of the CoreFoundation CFDateFormatterGetAbsoluteTimeFromString method.

#
Address
Category
Time
Size
Library
Caller


2280
0xa20be00
GeneralBlock-32
01:07.742
32
Foundation
-[NSDateFormatter getObjectValue:forString:range:error:]


2281
0xa219670
GeneralBlock-176
01:07.833
176
Foundation
-[NSDateFormatter getObjectValue:forString:range:error:]


2282
0xa298db0
GeneralBlock-48
01:07.833
48
Foundation
-[NSDateFormatter getObjectValue:forString:range:error:]

4. All 8618 Objects

The entire log (8618 entries) can be viewed here.

5. Conclusion

The StackOverflow.com positively isolates the problem and the workaround. Do not use setDateFormat:@”EEE, d MMM yyyy HH:mm:ss z“, unless you are willing to loose 868 Kb for the rest of the lifetime of the application. The alternative is to not use the time zone which is, I agree, a pain: setDateFormat:@”EEE, d MMM yyyy HH:mm:ss”.

A possible approach is to test the string against ” GMT”, and to only invoke “z” when not in GMT:

NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
[dateFormatter setTimeZone:[NSTimeZone timeZoneWithName:@"GMT"]];
if( ![string hasSuffix:@" GMT"]) {
    // If the string is not GMT, we must use time zone
    [dateFormatter setDateFormat:@"EEE, d MMM yyyy HH:mm:ss z"];
} else {
    [dateFormatter setDateFormat:@"EEE, d MMM yyyy HH:mm:ss"];
}


As of today’s date iPhone GB cost, your user either $0.005 or $0.01, depending on which device she or he bought.

6. External Links

• stackoverflow.com
  http://stackoverflow.com/questions/1117263/instruments-leaks-and-nsdateformatter
• Developer.apple.com
  Your tracking number for this issue is Bug ID# 7745113

Bookmark this on Delicious

Summary

1. Preventing over-release
2. [ -retain & -release] vs. [ -autorelease]
3. Circumventing -autorelease
4. NSAutoreleasePool is a stack object
5. NSAutoreleasePool pseudo-code
6. [pool release] vs. [pool drain]
7. External links

1. Preventing over-release

There seem to be some unpredictable stability behavior with objects that are released more than once (objects for which the -retainCount drops below 1). At times, some objects sent too many [ release ] will fail silently, whereas occasionally the host application will crash.

An application must balance the number of -retain and -release sent to a NSObject.

SomeObject * myObj = [[SomeObject alloc] init];
...
[myObj release];

To a certain extent, it would be better if over-release would never crash (akin to [ nil release ]) or always crash, thus not hiding bugs during the development stage. The combination of NSZombie and malloc_history is a wonderful tool to debug over-releasing. Read “Debugging Autorelease” on CocoaDev:
http://www.cocoadev.com/index.pl?DebuggingAutorelease

2. [ -retain & -release] vs. [ -autorelease]

Sending -autorelease to an object allows to literally forget about it. [ someObject -autorelease] ensures that someObject with a -retainCount of 1 will remain retained for the life of the NSAutoreleasePool it belongs to, and will receive a -release message when such pool receives -drain or -release. Generally, the question is “Which NSAutoreleasePool ?”. While the answer is “The most nested one, Sir.”, not knowing may lead to surprising behaviors. A defensive approach may be to only create only one NSAutoreleasePool for the entire duration of the application, but this is certainly a costly and rarely practical answer.

-autorelease, contrarily to -release, can be invoked more than once without ill effects.

For some reason, once an object received the -autorelease message, the operation cannot be undone. There is no -unautorelease message. Nor is there a way to tell the NSAutoreleasePool to just forget about that object.

This can lead to the following situations:

1. Preventing to save/release memory occupied by a given object
2. Preventing to delete that object at all before deleting the NSAutoreleasePool (sending one-too-many -release will cause the NSAutoreleasePool to send a -release to an already deallocated object, and crash)
3. Preventing the deletion of a given NSAutoreleasePool, since one cannot know what’s in it.

Following design patterns while being aware of these limitations is generally not a problem. A suggested approach is to use small scopes with local NSAutoreleasePool any time granularity can be achieved. In Cocoa, Threads do just that.

{
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
    SomeObject * myObj = [[SomeObject alloc] init];
    [myObj autorelease]; // No need to remember about that object
    ...
    [pool drain];
}

3. Circumventing -autorelease

Unfortunately, some Cocoa routines will, without a choice, drop objects it creates in the current NSAutoreleasePool.
Example:

UIImage * newImage = [UIImage imageWithCGImage:some_CGImageRef];

As a result, the caller has little or no control of when the new object will be destroyed. It will likely be deallocated when the NSAutoreleasePool to which it belongs is deallocated, which is generally not predictable.

The NSAutoreleasePool seems to be nothing more than a linked list which sends a -release message to all objects it contains (regardless of their state) upon drain. In a managed memory environment, the pseudo-code of NSAutoreleasePool -drain could be simplified like this:

-(void) drain {
    [autoreleasePool release];
}

Objects that for which the -retainCount is greater than 1 after the -drain will thus not be released. One can take an object out of a pool by retaining it, then releasing the pool entirely. Such object will be effectively removed from the NSAutoreleasePool.
Example:

UIImage * newImage = nil;
{
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
    newImage = [[UIImage imageWithCGImage:some_CGImageRef] retain];
    [pool drain];
}
// The  newImage* is now outside of the pool, and retained normally

An example of this technique can be found on Björn Sållarp’s article “UIImage with round corners”:
http://blog.sallarp.com/iphone-uiimage-round-corners

Note that in the example above, a special scope has been declared around the NSAutoreleasePool creation and destruction. This is good practice since the pool is actually a stack object, and must be created and released in the same { }. Please read on.

4. NSAutoreleasePool is a stack object

By nature, an NSAutoreleasePool instance is stored on the stack (as opposed to the heap). As a direct consequence, the scope of these pools, and ultimately of the objects they reference, are tightly coupled with the methods that created them. Even though the pools (just like the invocation of methods) are nested, there is no virtual stack of NSAutorelease pools.

As the method that created a given pool goes out of scope, so does that very pool, and all the objects referenced by it will receive a single -release message. For an object to survive a pool drain, it must be explicitly retained. See paragraph 3, Circumventing -Autorelease.

Being a stack object also makes it illegal to create an NSAutoreleasePool instance in a method, and to release it in another. This reason alone can serve as a good motivation for creating small, local and  nested NSAutoreleasePool rather than one gigantic one for the life of the Thread.

5. NSAutoreleasePool pseudo-code

In a managed memory environment, the NSAutoreleasePool acts pretty much like a NSArray. The pool maintains strong references to its content. Objects added to the pool receive a -retain message.

Possible pseudo-code for NSAutoreleasePool

 // .h
@interface NSAutoreleasePool2 : NSObject {
@private
    NSMutableArray * autoreleasePool;
}
-(void) drain;
-(void) addObject:(id)anObject;
-(id) autoreleaseObject:(id)anObject;
@end

// .m
@implementation NSAutoreleasePool2
-(id)init {
    if ((self = [super init] ) != nil ) {
        autoreleasePool = [[NSMutableArray alloc] init];
    }
    return self;
}
-(void) dealloc {
    [self drain];
    [super dealloc];
}
-(void) drain {
    [autoreleasePool release];
}
-(void) addObject:(id)anObject {
    [autoreleasePool addObject:anObject];
}
-(id) autoreleaseObject:(id)anObject {
    if( ! [autoreleasePool containsObject:anObject]) {
        [self addObject:anObject];
    }
    return anObject;
}
@end

Discussion

This is pseudo-code, not actual NSAutoreleasePool source code.
Objects must be added explicitly to this pool (using [pool autoreleaseObject:someObject ]; instead of [someObject autorelease];)
-autoreleaseObject is lenient, and will not penalize objects added more than once.
-addObject is strict ; objects added more than once will receive -release more than once.
-drain and -release do not have the same behavior. This pseudo-code expects an invocation to [pool release ] rather than [pool drain ] to free the NSAutoReleasePool2.

6. [pool release] vs. [pool drain]

In a reference-counted environment sending -release or -drain to a NSAutoreleasePool has the same effect.

In a garbage-collection environment, without NSAutoreleasePool, -release has no effect while -drain triggers garbage collection. For this reason, the developer documentation explicitly recommends using  -drain, since it has a meaning in both management models, even on iPhone.

Read more about NSAutoreleasePool -drain on Apple’s developer site:
http://developer.apple.com/mac/library/documentation/cocoa/reference/Foundation/Classes/NSAutoreleasePool_Class/Reference/Reference.html

7. External links

• http://www.cocoadev.com/index.pl?DebuggingAutorelease
• http://blog.sallarp.com/iphone-uiimage-round-corners/
• http://developer.apple.com/…/NSAutoreleasePool_Class/…

Bookmark this on Delicious

An Android (such as the Google G1 phone) can be tethered to a computer running Mac OS X, allowing the computer to browse the web. The device is connected to the computer using a USB cable. The web is browsed with Firefox. The detailed communication procedure is documented here.

This article is only intended to give a brief overview of AndroidTether and provide a link to the download page.

1. overview
2. copyright and guaranties
3. download AndroidTether
4. launch AndroidTether
5. advanced preferences

1. Overview

1.1 What is Tetherbot?

Tetherbot enables an Android device (such a Google G1 cellular phone) to be used as a network interface to provide a MacIntosh OS X laptop with an Internet data connection. It provides mobile, wide-area Internet access for the computer via the cellular-phone network — for instance where unrestricted WiFi is not available. This process is generally referred to as “tethering.”  In addition to expanding the range of Internet access for the OS X computer, Tetherbot enables the features of the OS X device to overcome the limitations of the Android device, so that one can use a more fully featured keyboard and Flash-enabled web browser (Firefox), to access webbase e-mail and browse the web efficiently. Tetherbot runs on the Android device, and requires a mirror application to run on the computer.

1.2 What is AndroidTether?

AndroidTether is designed to automate the process of tethering and eliminate the need to reconfigure your computer system every time you wish to tether. You should refer to the terms of service of your cellular service provider before tethering. AndroidTether runs on the computer, and connects to Tetherbot.

2. Copyright, guaranties, cost.

Copyright

Written by (c) Xavier Schott 2009.

Guaranties

none.
The software is provided  “AS IS”; “thegothicparty.com/dev” and “the author” make NO GUARANTIES and NO WARRANTIES OF ANY TYPE, expressed or implied, including NO WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Again, none.

Cost

free

3. Download AndroidTether

Start here:

Download AndroidTether 0.91 for Mac OS X.

4. Launch AndroidTether and Tetherbot

Tethering is automatically started upon launch, and stopped when quit.
You can also stop and restart the connection using the Stop/Start button.
Thus, when you are done, simply quit AndroidTether. Refer to the complete procedure, device installation requirements, and how to use Tetherbot  here.

5. Advanced Preferences

It is possible to change AndroidTether ports to accommodate to changes in Firefox or Tetherbot.
The local port (left number) refers to the SOCKS Host: localhost Port: 1080 setup in Firefox

The remote port (right number) refers to Socks Proxy Server on: 1080 setup in Tetherbot

Note:
AndroidTether will conflict with adb. You cannot use adb and AndroidTether simultaneously.

6. External links

• Android proxy

Bookmark this on Delicious

This mechanism requires two independent pieces of software, namely Tetherbot on the Android device, and AndroidTether (or alternatively Terminal and the Android SDK) on the Macintosh.

The objective of this article is to clarify the installation and setup process for Mac OS X. It does not apply to other operating systems.
A general understanding the Tetherbot documentation may be helpful.
The screen shots relate to Tetherbot.apk 39.57KB” (in lieu of a better version) and Firefox 2.0.0.16 on Mac OS X 10.5.5.

This article is divided in 2 sections:

1. Things to do every time
   • Launch Tetherbot on the device
   • Launch AndroidTether on the computer
     (alternatively, launch Terminal on the computer)
   • Change some Firefox preferences
2. Installation to be done just once
   • Installation of Tetherbot on the device
   • Installation of AndroidTether on the computer
     (alternatively, install the Android SDK)
   • One-time Setup of the device
   • One-time Firefox setup

1. Things to do every time

1.1. Launch Tetherbot on the device

Connect the computer to the device using a USB cable.
Launch Tetherbot and tap “Start Socks”.
If everything goes well, the proxy server will start on port 1080.

1.2. Launch AndroidTether on the computer

Starting AndroidTether will automatically setup the connection.

1.3. (alternatively, launch Terminal on the computer)

On the Macintosh, launch a Terminal window. Assuming here that you have installed the Android Software Development Kit. See step 2.3 for details.
In Terminal, type exactly “adb forward tcp:1080 tcp:1080“.
Note that the syntax is “adb forward tcp:{local port} tcp:{remote port}“.
The {local port} is the SOCKS host mentioned in section 1.4
The {remote port} must match Socks Proxy Server on: 1080 mentioned in section 1.1

1.4. Change some Firefox* preferences

On the computer, launch Firefox.
Go to “Firefox>Preferences…>Advanced>Network>Settings…”.

• “Manual proxy configuration:”
• “SOCKS Host:” to “localhost”, “Port:” 1080
• “SOCKS v5″

Note that “Port: 1080″ represents this time the {local port} parameter in “adb forward tcp:{local port} tcp:{remote port}”.

Firefox is now ready to browse the Internet.
Restore the original setting after you are done tethering the device or you won’t be able to browse the web with Firefox. For added security, restore item 2.5 as well.

(*) Safari does not provide preferences to manually change the proxy, which is a sine qua non condition for the entire mechanism to function. System Preferences must be changed instead, with various levels of success.

2. Installation to be done just once

2.1. Installation of Tetherbot on the device

2.1.1. Prior downloading Tetherbot on the G1, you must change the “Home>MENU>Applications>Unknown sources” setting and “Allow install of non-Market application”.
Warning, this is a dangerous and potentially unsafe action. Review the warning carefully.

2.1.2 Using the G1 Brower, go to http://graha.ms/androidproxy/Tetherbot.apk to download Tetherbot.

2.1.3. After download completes on the device, simply select the “.apk” Android Package to install.

2.2. Installation of AndroidTether on the computer

AndroidTether is a Macintosh OS X application that will setup the computer side of the communication automatically.
It runs in just one click, and does not require the download of the entire Android SDK.
AndroidTether is lightweight, flexible, free, and can be downloaded here.

2.3. (alternatively, install the Android SDK)

Install the Android Software Development Kit.
Once installed, follow the instructions on adding android-sdk-mac_.../tools to your PATH.
The alternative is to execute adb from the tools directory:
( cd .../android-sdk-mac_.../tools ; ./adb forward ...)

2.4. One-time setup of the device

To use Tetherbot, you will need to perform these operations:

On the device, turn on “USB debugging”
“Home>MENU>Settings>Applications>Development>USB debugging”
Additionally, you may want to turn on “Stay awake” as well.

2.5. One-time Firefox setup

This change allows Firefox to fetch DNS information from the proxy. You must allow it to tether the device.
For maximum security, restore it to false after each use.

1. In Firefox, File>Open Location… about:config.
2. Add the Filter: “dns” for clarity
3. select the Preference network.proxy.socks_remote_dns and set it to true
(hit <enter> or right-click).

These changes have been tested on Firefox 2.0.0.16 and Firefox 3.0.5.

3. External links

• Tetherbot
• AndroidTether
• Android Software Development Kit
• Tetherbot.apk

Bookmark this on Delicious

Mission Statement:
Post software development insights as I come across them.