TweetFollow Us on Twitter

AOCE Mailer
!seealso: "AOCE" "Messaging Service" "DigiSign"
Volume Number:10
Issue Number:2
Column Tag:AOCE

Using The AOCE Standard Mailer

Adding Standard Mailer support to MacWrite Pro

By Lee Richardson, Claris Corporation

Note: Source code files accompanying article are located on MacTech CD-ROM or source code disks.

About the author

Lee Richardson is the MacWrite Pro Project Manager at Claris, has been doing software in various forms for over ten years, and has been working for Claris way longer than he ever thought he’d work for any company. He’s available on AppleLink (RICHARDSON7) or CompuServe (74155,435).


MacWrite Pro 1.0, from Claris Corporation, is the latest in a long line of products that started with the original MacWrite in 1984. MacWrite has gone through several revisions since then, with the current release offering a variety of high-end word processing and page layout features. MacWrite has always been known for its ease of use; MacWrite Pro continues that philosophy.

As part of the 1.5 release of MacWrite Pro, we’ve included support for Apple’s Open Collaboration Environment (AOCE) by adding Standard Mailer functionality. The Standard Mailer provides a high-level interface to AOCE, and includes automatic mailer drawing, mail addressing, catalog management, and support for enclosed files. By using the Standard Mailer, MacWrite Pro users can more easily share documents with others, and can stay in the same environment for both word processing and email tasks.

In this article, I’m going to describe the steps we went through to add Standard Mailer support to MacWrite Pro. I’ve also included sample code that shows how to read and write the different letter formats, and how to handle letters in both the mailbox and on disk.

Note: in the sample code, you’ll see the TRY/CATCH exception mechanism in use. This is an exception handler originally used in MacApp that simplifies error trapping (a similar scheme is used in C++). If an error occurs in the TRY block, execution is transferred to the first instruction in the CATCH block, then optionally back to the CATCH block in the caller. It’s a handy way to handle errors, but doesn’t otherwise affect the Standard Mailer examples.

Document Format

When we started working out the details of adding Standard Mailer support to MacWrite Pro, the first decision we ran into concerned how letters were to be represented in memory. It initially appeared that letters might be very different document types, and would need their own document format and saving code. But it eventually turned out that there were mostly similarities, and that our existing document structure, with a couple of additions, would suffice. Those additions consisted of flags for whether the document had a mailer, if the mailer was expanded or contracted, whether the mailer or the document was the current target, and the current height of the mailer, in pixels. We also added a LetterDescriptor (described later) giving the current location of the letter.

Adding a Mailer

Let’s start with a definition: a mailer is the addressing block that appears at the top of mail capable documents. It includes information about who the letter is from, who to send it to, the subject of the letter, and a list of enclosed files. Apple recommends that the mailer appear at the top of the document, just under the title bar, which is where we put it (we also considered a separate floating window, but decided the mailer information would be more clearly associated with the document if it was part of the document window).

The Mailer in a MacWrite Pro Document

You create a mailer and attach it to a document with the SMPAddMailer() routine. You specify a document window the mailer belongs to, various setup preferences, and an optional drawing callback routine. We use the callback to set the window origin correctly for the mailer, then set the origin to a different value for drawing the rest of the document. SMPAddMailer() doesn’t draw anything, but merely creates a mailer and associates it with a particular document.

One potential gotcha when you add a mailer has to do with scroll bars. The mailer contains two scroll bars - one each for the Recipients and Enclosures lists. These are added to the control list of the window when you call SMPAddMailer() (or any of the other routines that open a letter). If you already have controls in that list, and locate them by absolute position (like we used to), you’ll get some pretty strange results when you start scrolling and updating your window (there was a short period during our development when clicking on the vertical scroller actually moved the whole document to the left). A couple of solutions are to locate your controls by name, or save duplicates of the ControlHandles somewhere else.

Drawing Mailers

Most of the work in drawing a mailer in the MacWrite Pro document window involved moving all the window elements down and out of the way. In our case, the window contents all assume an upper left origin of (0,0), so it was a straightforward process to patch the origin-setting code to back up the height of the mailer and open up space at the top of the window. For example, if the mailer is currently 20 pixels high, we’ll set the origin to (-20, 0), then all the code that draws window elements starts drawing 20 pixels lower than usual. When we draw the mailer, the drawing callback resets the origin to (0,0) and the mailer happily draws itself right at the top.

Once you have a place for the mailer, you draw it by calling SMPDrawMailer(). We do specific updates when creating, deleting, or expanding the mailer, and on update events.

Event Handling

The documentation recommends sending all events directly from WaitNextEvent() to the Standard Mailer, via SMPDoMailEvent(), which we do. We then check the return code for any required actions on our part. This involves things like expanding or contracting the mailer, making either the mailer or document the current target (specifying which is hilighted and gets key events), and taking down any of our help balloons when the cursor is over the mailer.

Edit Menu

The Standard Mailer provides support for the basic Edit menu items when you’re in the mailer. This includes Cut/Copy/Paste of both subject text and addressing information, Select All/Clear for those same fields, and Undo for editing operations. You need to do your own menu tracking, and tell the mailer when anyone has selected any of those items. There’s also functionality within the mail code that provides a seamless match between undo within the mailer, and undo within your document window.

Letter Formats

The next section talks about sending a letter, but before we get into that, we need to discuss letter formats. A Standard Mailer letter is a document that can contain information in one or more formats. These formats are stored in blocks that are both written and read by Standard Mailer routines, so you never have to deal with them directly.

There are two standard mail formats: Standard Interchange, a styled text format that can include inline graphics, sounds, and movies, and Snapshot, which is a series of images of your document. Both of these formats can be read by the AppleMail application, which is included with System 7 Pro. If you include either of these formats in your letters, they can be read by anyone with a copy of AppleMail.

You can also create your own letter format, using the block structure of letters. This could be used to store a native version of your document, or any other data you want to include with the letter.

Finally, you can save a single document as the main enclosure of a letter. The document file is included in its entirety in the letter, but does not appear in the Enclosures list of the mailer. This is handy if you already have file saving code and don’t want to change it to use the letter block structure, and is the solution we use in MacWrite Pro for native formats.

Sending a Letter

Before doing anything, you need to check the letter to make sure it has both a subject and at least one recipient (see the routine Mail_SendSetup()). When that’s done, you put up the Send Options dialog with the SMPSendOptions() routine. This dialog, which is similar in usage to the Print dialog, lets the user select which formats to use, a high/medium/low letter priority, and whether to sign the letter with a digital signature. You control which formats are displayed, both for the standard formats and your own, and you can create a list if you have more than one. MacWrite Pro uses this latter capability to provide a list of XTND translators that can be used for letter sending.

Once you have a format selection, you need to send the format(s) (see Mail_Send()). You start the send process by calling SMPBeginSend(), write out each of the selected formats, then end the process with SMPEndSend(). SMPBeginSend() will check to make sure you actually need to write content (you may be forwarding a letter that hasn’t been changed, for example); SMPEndSend() closes the letter and sends it.

Native Formats

Sending your own native document, if you use the main enclosure scheme, is pretty easy: get an FSSpec for the Temporary Folder with FindFolder() and FSMakeFSSpec(), save your document there by doing a normal save, then hand the document off to the Standard Mailer with SMPAddMainEnclosure(). See the routine Mail_FailWriteDoc() for details.

Standard Interchange

Sending the Standard Interchange format is a little more involved, but still straightforward. The general plan is to write your document content in blocks, which are contiguous chunks of similar data. There are blocks for styled text, PICTs, QuickTime movies, and sound (in AIFF format). Every time you change a block type, you’ll tell the Standard Mailer so it can keep track of which is which.

For example, let’s say you’re sending a one-page letter that has a half-page of text, an inline graphic in the center, followed by another half-page of text. The first block you write will be a styled text block, consisting of the first half-page of text. You’ll then write a PICT block for the graphic, then finish up with a third styled text block for the last half-page of text. The example fragment below illustrates how SMPAddContent() is used.

/* 1 */
Mail_GetContiguousText(theDoc, &textOffset, 
 textHdl, styleHdl);
SMPAddContent(theDoc, kMailStyledTextSegmentType, 
 kNewSegment, *textHdl, GetHandleSize(textHdl), 
 *styleHdl, kNewScript, smRoman);

Mail_GetPICT(theDoc, &textOffset, thePICT);
SMPAddContent(theDoc, kMailPictSegmentMask, kNewSegment, 
 *thePICT, GetHandleSize(thePICT), nil, kSameScript, 0);

Mail_GetContiguousText(theDoc, &textOffset, 
 textHdl, styleHdl);
SMPAddContent(theDoc, kMailStyledTextSegmentType, 
 kNewSegment, *textHdl, textLength, *styleHdl, 
 kSameScript, smRoman);

kNewSegment is my constant that equals FALSE and says that we aren’t appending the same content type as the previous SMPAddContent() call. You’d use TRUE here if you were adding several styled text blocks in a row. kNewScript equals TRUE and shows that we’re starting a new script block. kSameScript is FALSE and is used as long as you remain in the same script system.

Since the text block formats are the same as styled text scrap formats, we were able to use the MacWrite Pro code that converts our internal format to external scrap formats to generate the letter block information (in essence, copying and pasting our way through the document and into the letter).


An advantage of sending a letter using the Standard Interchange format is that the recipient of your letter gets editable text. A disadvantage, though, is that you can lose information in the process (MacWrite Pro, for example, doesn’t include the contents of headers or footers, or any floating text frames or tables you might have). You may also have a document type that doesn’t lend itself well to Standard Interchange (like a drawing or database application). Snapshot format is a way to send your document as a set of images, which appear exactly as seen on screen or on the printer.

To send a letter in Snapshot format, you call SMPImage() to set up the drawing environment, and include a callback routine that does the actual imaging. This callback routine draws the cover pages, which provide the addressing information showing in the mailer(s), then steps through each page in your document and draws it to the current port as set up by SMPImage(). See the example routines Mail_FailWriteSnapshot() and Mail_DrawPages() for more details.

Saving a Letter

Saving a letter on disk is almost exactly the same as sending it, except that you choose the formats that are saved. We include a MacWrite Pro main enclosure document as the richest form of the content, and do Standard Interchange format so that anyone can read the letter with AppleMail. We use our own creator and file types, and our own icon.

A potential confusion involving letters saved through the Standard Mailer is that you can’t read them if AOCE is not present. Since the letter is saved using the Standard Mailer block format (or using the Standard Mailer main enclosure), there’s no way to retrieve the information without it. We deal with this in MacWrite Pro 1.5 by putting up an alert if someone attempts to open a letter on a system that doesn’t have AOCE installed.

Opening Letters

A letter can exist either on disk or in the PowerTalk mailbox (the In Tray). If it’s on disk, it’s treated as a regular file, and can be opened through a regular SFGetFile call or by an ‘odoc’ AppleEvent. This would be pretty standard, except that AOCE identifies letter documents with a special Finder flag. This flag (0x0200, the former ‘changed’ bit) shows that an incoming document is a letter and may contain one of the standard formats (using a Finder flag makes it possible to use different file types, yet still identify a document as a letter). If you support either Standard Interchange or Snapshot formats, you should check that bit in any incoming documents with GetFInfo(), then open the document regardless of its file type.

If a letter is in the mailbox, you won’t be able to see it in the standard file dialog, so the only way to open it is by double-clicking it. This also generates an ‘odoc’ event, except that instead of getting an FSSpec in the event, you’ll get a LetterSpec, which is a structure unique to letters in the mailbox. The Standard Mailer provides a LetterDescriptor data structure that handles both of these cases:

/* 2 */

struct LetterDescriptor {
 union {
 FSSpec fileSpec;
 LetterSpec mailboxSpec;

The only unclear aspect of this process is that you have to set it up yourself, based on the event you get. See the sample routine Mail_DoOpenDoc() to see how it works.

Reading a Letter

Opening and reading the contents of a letter reverses the send or save process, except that you don’t know what’s there until you look. We go through the following steps:

1) Is there a main enclosure? If so, get it and see if we can open it, either as a native doc or using XTND

2) If no main enclosure, or we can’t read what’s there, are there any any standard interchange blocks? If so, read them.

3) No doc yet? Look for image blocks and read them.

4) Still no doc? Create an empty one so the user can get to any enclosures that might be attached.

We initially attempted to let the user know if there were no readable formats in the letter. However, an empty document looks the same as a document with no readable formats, so we just open an empty letter if there’s nothing there.

There are a couple of inelegant sides to opening letters. The first one is that letters (mailers) are always attached to windows. For example, when you open a letter with SMPOpenLetter(), the first parameter is a LetterDescriptor, and the second is the doc window you’re going to display the letter in. However, in MacWrite Pro we don’t have a doc window yet, and won’t until we either open the main enclosure, or create a doc for one of the other formats. I tried using our clipboard window as a temporary window, but ran into a performance problem with opening the letter twice (AOCE is not fast), and had a more fundamental problem with the kSMPCopyInProgress error described below. I ended up creating my own doc window for opening the letter, then patching the rest of the application to use that window when creating or opening a document. Tacky, but it worked.

The other problem you’ll potentially run into has to do with error recovery during your open. If you open the letter, then run out of memory later in the process, you’ll probably want to close the letter and dispose of that window. However, the SMPPrepareToClose() routine will somewhat sporadically return a kSMPCopyInProgress error when you attempt to close it. Bad juju. According to MacDTS, this has something to do with the open event not having completed yet and therefore not clearing that flag. What it means is that you have to keep that window around until the Standard Mailer will let you close it. The best way is to check the window somewhere in the main event loop, then close and dispose of it when SMPPrepareToClose() finally comes back with noErr. (If anyone else has a better solution, please let me know.)

A simplified version of opening letters is shown in the routine Mail_OpenLetter().

Reading Main Enclosures

This is easy. Once you’ve opened the letter, look for the main enclosure with SMPGetMainEnclosureFSSpec(). If you get a fileSpec back, you can do whatever is necessary to open it (or avoid opening it, if it’s not in a format you recognize).

Reading Standard Interchange

The pertinent routine here is SMPReadContent(). You step through all the standard interchange blocks, which again can be text, styled text, PICTs, movies, or sounds, read each one in, figure out what you have, then drop it into your document. In MacWrite Pro, this is the opposite process from writing this format out, in that we essentially get successive scrap elements from SMPReadContent() and paste them into the main body of the document.

Reading Snapshots

This is a little more interesting. When you created the snapshot, the Standard Mailer saved each imaged page as a separate PICT, the same size as your page, into one or more image blocks. Each image block starts with a TPfPgDir struct, which tells you how many pages there are in that block, and the offset of each PICT that describes that page. You use SMPReadBlock() at the start of each block to retrieve the struct, then loop through each of the pages and read the PICT from the specified offset using the specified length (also using SMPReadBlock()). When you get to the end of the pages, you read the next block. When you get a kIPMBlkNotFound error, you’re done.

The fun part of this format is that you get a bunch of page-size pictures of the original document, which you then have to figure out what to do with. We ended up sizing the document margins to match the first PICT, then pasting each picture into successive pages as inline graphics. There’s something pleasantly twisted about a word processing document that looks like a real doc, has text like a real doc, but is really just pictures masquerading as a document (sort of like the plastic food you’ll see in the windows of Japanese restaurants). See the sample routine Mail_FailReadImage() for the gory details.

Reply and Forward

Once you’ve opened a letter, you may want to reply to it. Recommended practice is to give the user a choice between Reply to Sender and Reply to All, which you can either do through two separate menu items or as a dialog with a couple of radio buttons; we chose the latter. To create the reply, we make a new document, copy the original text into it with a header at the top (showing who wrote the original and when), then turn that document into a reply with the SMPMailerReply() routine. SMPMailerReply() uses the addressing information from the original to set up the mailer attached to the reply, and sets the recipient list using the answer from the earlier Reply to Sender/All question. After the reply is created, it’s treated like a regular letter, and can either be sent or saved as requested.

Forwarding a letter is trivial, and consists of a single call to SMPMailerForward(). This routine overlays another mailer over the existing topmost mailer, whereupon the user can address it and send it or save it.


The final thing to think about is Mail Preferences. MacWrite Pro gives users the ability to specify whether mailers are expanded or collapsed when creating, opening, or replying to a letter, whether to include the original text in a reply, and, optionally, whether to style or color the original text. The AppleMail application does something similar.


That covers the basics of adding Standard Mailer support to a product. I found the process to be straightforward, once I got past my initial surprise at the quantity of routines in the Standard Mailer. With a couple of minor exceptions, dealing with the Standard Mailer has been quite pleasant - it does everything it says it does, and, so far, has done everything I need.

Other sources of information include the AOCE Application Interfaces manual from Apple and the Standard Mailer sample application CollaboDraw, included with the System 7 Pro developer’s kit. CollaboDraw is pretty handy for figuring out the overall structure of Standard Mailer support. You can also check out the AppleMail application, automatically included with System 7 Pro, for mailer handling, preferences, and other usage items.

In closing, I’d like to thank Scott Lindsey at Claris for giving help above and beyond the call of duty during my Standard Mailer implementation, both for information provided and code graciously explained.

/* 3 */

// --------------------------------------------------------------
void Mail_Send(DocumentPtr theDoc)
 OSType ltrCreator;
 short  okToSend = true;
 SMPSendOptions  sendOptions;
 SMPSendFormat   sendFormat;

 FailFalse(Mail_SendSetup(theDoc, &sendFormat, 
 if (sendFormat.whichFormats & kSMPNativeMask)
 // we're doing our native format, so make it our document
 ltrCreator = kMyCreatorType;
 // if we're not including our native format, 
 // always make it an AppleMail doc
 ltrCreator = kAppleMailCreator;
 // start the sending process
 FailOSErr(SMPBeginSend((WindowPtr) theDoc, ltrCreator, 
 typeLetterSpec, &sendOptions, &mustAddContent));
 // if the Standard Mailer says the letter has changed
 // from the last version, rewrite the content
 if (mustAddContent)
 if (sendFormat.whichFormats & kSMPNativeMask)
 if (sendFormat.whichFormats & kSMPImageMask)
 if (sendFormat.whichFormats & 
 // tell the mail system we’re cancelling
 okToSend = false;
 // we’re done
 FailOSErr(SMPEndSend((WindowPtr) theDoc, okToSend));
} // end Mail_Send

// --------------------------------------------------------------
short Mail_SendSetup(DocumentPtr theDoc, 
 SMPSendFormat *sendFormat, SMPSendOptionsPtr sendOptions)
 unsigned short  subjectSize, toSize;
 OSErr  myErr = noErr;
 Str255 appName, docName;
 StringPtrappNamePtr[1] = appName;

 // make sure the letter has a subject
 SMPGetComponentSize((WindowPtr) theDoc, 1, kSMPRegarding, 
 if (subjectSize <= offsetof(RString, body))
 Mail_SetError(SMPBecomeTarget((WindowPtr) theDoc, true, 
 return false;
 // also make sure the letter has at least one recipient
 SMPGetComponentSize((WindowPtr) theDoc, 1, kSMPTo, &toSize);
 if (!toSize)
 Mail_SetError(SMPBecomeTarget((WindowPtr) theDoc, true, 
 return false;
 // get the app name for our native format
 GetIndString(appName, kInfoStrID, kAppNameItem);
 GetWTitle((WindowPtr) theDoc, docName);
 // do the options dialog. We’re only going to show
 // one native format, along with Snapshot and
 // Standard Interchange.
 myErr = SMPSendOptionsDialog((WindowPtr) theDoc, docName, 
 appNamePtr, 1, kSMPNativeMask + kSMPImageMask + 
 sendFormat, nil, nil, sendFormat, sendOptions);
 if (myErr && myErr != userCanceledErr)
 return myErr ? false : true;
} // end Mail_SendSetup

// --------------------------------------------------------------
pascal void Mail_DrawPages(long refcon, Boolean inColor)
 #pragma unused(inColor)

 DocumentPtrtheDoc = (DocumentPtr) refcon;
 short  i;
 short  pageCount;
 OpenCPicParams  picHeader;

 // set everything in picHeader to 0, then set non-zero values
 Mail_ClearRecord(&picHeader, sizeof(picHeader));
 picHeader.srcRect.bottom = theDoc->pageLength;
 picHeader.srcRect.right  = theDoc->pageWidth;
 picHeader.hRes  = theDoc->hRes << 16;
 picHeader.vRes  = theDoc->vRes << 16;
 picHeader.version = -2;
 // draw the cover pages
 gMyErr = SMPPrepareCoverPages((WindowPtr) theDoc, &pageCount);
 for (i = 1; i <= pageCount && gMyErr == noErr; ++i)
 if (!(gMyErr = SMPNewPage(&picHeader)))
 gMyErr = SMPDrawNthCoverPage((WindowPtr) theDoc, i, 
 i == pageCount);
 // step through each page in the document and draw it
 for (i = 1; i <= theDoc->pageCount && gMyErr == noErr; ++i)
 if (!(gMyErr = SMPNewPage(&picHeader)))
 // do whatever's necessary to draw a document page
 gMyErr = Mail_DrawOnePage(theDoc, i);
} // end Mail_DrawPages

// --------------------------------------------------------------
OSErr Mail_OpenLetter(LetterDescriptor *letterDesc)
 volatile DocumentPtrtheDoc = nil;
 OSErr  myErr    = noErr;

 FSSpec mainEncSpec;
 const PointtopLeft= {0, 0};
 const Rect boundsRect  = {0, 0, 120, 120};
 SMPMailerState  mailerState;
 short  mailerWidth;
 short  contractedHeight;
 short  expandedHeight;

 // do some memory preflighting
 FailWithErr(Mail_AvailableMem() < kMinToCreateDoc, 
 // this should not fail, after the above test. But 
 // let's check anyway.
 FailNull(theDoc =
 (DocumentPtr) NewPtr(sizeof(DocumentRecord)));
 // we create a ‘real’ document later, need WindowPtr now
 theDoc = (DocumentPtr) NewWindow(theDoc, &boundsRect, "\p", 
 false, documentProc, nil, true, 0);
 SetPort((WindowPtr) theDoc);
 BlockMove(letterDesc, &theDoc->theLetter, 
 // open the letter. This is equivalent to adding a mailer.
 (WindowPtr) theDoc, topLeft, kCanContract, true, 
 Mail_DrawingSetup, nil));
 theDoc->isMailer = true;
 // see if there’s a main enclosure file
 myErr = SMPGetMainEnclosureFSSpec((WindowPtr) theDoc, 
 if (myErr == noErr)
 myErr = Mail_OpenDocument(&mainEncSpec);
 // fnfErr here either means there was no main enclosure,
 // or we couldn’t read it
 if (myErr == fnfErr)
 myErr = Mail_ReadStdInterchange(theDoc);
 if (myErr == fnfErr)
 myErr = Mail_ReadImage(theDoc);
 // if we couldn’t find anything, just do an empty letter.
 if (myErr == fnfErr)
 myErr = Mail_CreateNewDoc(theDoc);
 FailOSErr(SMPGetMailerState((WindowPtr) theDoc, 
 if (theDoc->theLetter.onDisk)
 // the letter exists as a file on disk, so use the 
 // file name as the window title
 SetWTitle((WindowPtr) theDoc, 
 SMPLetterInfo letterInfo;
 // we're opening the doc from the In Tray, so use the
 // subject as the window title
 &theDoc->theLetter.u.mailboxSpec, &letterInfo));
 SetWTitle((WindowPtr) theDoc, 
 OCERToPString((RStringPtr) &letterInfo.subject));
 // get the mailer sizes, and save the pertinent one
 FailOSErr(SMPGetDimensions(&mailerWidth, &contractedHeight,
 theDoc->mailerHeight= mailerState.isExpanded ? 
 expandedHeight : contractedHeight;
 theDoc->mailerState = mailerState.isExpanded ? 
 kExpandedMailer : kContractedMailer;
 // actually draw the window
 ShowWindow((WindowPtr) theDoc);
/* if we get an exception, we'll probably have a window to get rid of. That window 
will have a mailer, which we need to dispose. However, we probably can't dispose of 
the mailer yet, because of the silly kSMPCopyInProgress error. So take a shot at the 
mailer, and if it goes away, dispose of the window. But if it doesn't go away, save 
the window for later, and we'll dispose of it and the mailer in _DoEvent after we've 
gone through the event loop a time or two. See the article text for more information. 
 if (theDoc && theDoc->isMailer)
 OSErr closeErr;
 if (!(closeErr = SMPPrepareToClose((WindowPtr) theDoc)))
 closeErr = SMPDisposeMailer((WindowPtr) theDoc, nil);
 if (!closeErr)
 theDoc->isMailer = false;
 if (theDoc)
 if (!theDoc->isMailer)
 gDisposeThisDocument = theDoc;
 theDoc = nil;
 Mail_SetError(myErr = THISERROR);
 return myErr;
} // Mail_OpenLetter


Community Search:
MacTech Search:

Software Updates via MacUpdate

Latest Forum Discussions

See All

How to get started with Prisma
If there's one thing people like to do more than taking pictures with their smartphones, it's tinkering with those photos in some way. Numerous apps have sprung up over the last several years that allow you to use filters and special effects to... | Read more »
6 Pokemon GO updates you can expect, acc...
Pokemon GO had a scheduled appearance at this year's San Diego Comic-Con for a while, but it was only relatively close to the show that it was upgraded to a spot in Hall H. That's the biggest venue at SDCC, one usually reserved for the largest... | Read more »
How to evolve Eevee in Pokemon GO
By now, almost everyone should be hip to how to evolve Pokemon in Pokemon GO (and if not, there's a guide for that). Just gather enough candy of the appropriate type, feed them all to the Pokemon, and evolution happens. It's a miracle that would... | Read more »
CSR Racing 2: Guide to all game modes
It might not seem like there are all that many ways to go fast in a straight line, but CSR Racing 2 begs to differ. [Read more] | Read more »
Bulb Boy (Games)
Bulb Boy 1.0 Device: iOS Universal Category: Games Price: $2.99, Version: 1.0 (iTunes) Description: Multi-award winning 2D point & click horror adventure about a boy with a glowing head. | Read more »
5 top free emoji keyboard apps
If we're not at peak emoji yet as a society, it feels like we definitely should be. The emoji concept has gone far beyond what anyone in Japan could have envisioned when the people there unleashed it on an unsuspecting world, but the West has... | Read more »
How to unlock more characters in Disney...
One of the big charms of Disney Emoji Blitz is seeing a wide variety of beloved Disney and Pixar characters transformed into smiling emojis. Even someone like the sneaky Randall from Monsters Inc., who probably never cracked a smile on film, is... | Read more »
Cubway (Games)
Cubway 1.0 Device: iOS Universal Category: Games Price: $1.99, Version: 1.0 (iTunes) Description: Cubway is a journey with an abstract story of lifecycle of rebirth, called Samsara. Guide the cube through the long way full of dangers... | Read more »
Colorcube (Games)
Colorcube 1.0 Device: iOS Universal Category: Games Price: $1.99, Version: 1.0 (iTunes) Description: Turn pieces and blend colours in this minimal yet visually stunning puzzler.Over 200 handcrafted and challenging levels. Features... | Read more »
Doodle God Griddlers (Games)
Doodle God Griddlers 1.0 Device: iOS Universal Category: Games Price: $4.99, Version: 1.0 (iTunes) Description: | Read more »

Price Scanner via

13-inch 1.6GHz/128GB MacBook Air on sale for...
Amazon has the 13″ 1.6GHz/128GB MacBook Air on sale for $200 off MSRP for a limited time. Shipping is free: - 13″ 1.6GHz/128GB MacBook Air (sku MMGF2LL/A): $799.99 $200 off MSRP Their price is the... Read more
13-inch 1.6GHz/256GB MacBook Air on sale for...
Amazon has the 13″ 1.6GHz/256GB MacBook Air on sale for $200 off MSRP for a limited time. Shipping is free: - 13″ 1.6GHz/256GB MacBook Air (sku MMGG2LL/A): $999.99 $200 off MSRP Their price is the... Read more
Free iOS Business App notably* Helps Service...
PayStudio Inc. has introduced their new business app notably* 1.0, developed for iPhone and iPod touch. notably* was specifically developed to help service and trade professionals go digital and... Read more
27-inch iMacs on sale for $200 off MSRP
Amazon has 27″ iMacs on sale for $200 off MSRP including free shipping: - 27″ 3.3GHz iMac 5K: $2099 $200 off MSRP - 27″ 3.2GHz/1TB Fusion iMac 5K: $1799.99 $200 off MSRP - 27″ 3.2GHz/1TB HD iMac 5K... Read more
Mac Pros on sale for $200 off MSRP
B&H Photo has Mac Pros on sale for $200 off MSRP. Shipping is free, and B&H charges sales tax in NY only: - 3.7GHz 4-core Mac Pro: $2799, $200 off MSRP - 3.5GHz 6-core Mac Pro: $3799, $200... Read more
Save up to $600 with Apple refurbished Mac Pr...
Apple has Certified Refurbished Mac Pros available for up to $600 off the cost of new models. An Apple one-year warranty is included with each Mac Pro, and shipping is free. The following... Read more
Apple price trackers, updated continuously
Scan our Apple Price Trackers for the latest information on sales, bundles, and availability on systems from Apple’s authorized internet/catalog resellers. We update the trackers continuously: - 15″... Read more
13-inch 2.5GHz MacBook Pro (Apple refurbished...
Apple has Certified Refurbished 13″ 2.5GHz MacBook Pros available for $829, or $270 off the cost of new models. Apple’s one-year warranty is standard, and shipping is free: - 13″ 2.5GHz MacBook Pros... Read more
21-inch iMacs on sale for up to $120 off MSRP
B&H Photo has 21″ iMacs on sale for up to $120 off MSRP including free shipping plus NY sales tax only: - 21″ 3.1GHz iMac 4K: $1379 $120 off MSRP - 21″ 2.8GHz iMac: $1199.99 $100 off MSRP - 21″ 1... Read more
Charitybuzz Set to Auction Unique Apple-1 Com...
Offering an opportunity to own the computer that sparked a revolution, on Monday, July 25, leading online charity auction platform Charitybuzz will auction what is claimed to be the world’s most... Read more

Jobs Board

*Apple* Retail - Multiple Positions, Willow...
Job Description:SalesSpecialist - Retail Customer Service and SalesTransform Apple Store visitors into loyal Apple customers. When customers enter the store, Read more
*Apple* Evangelist - JAMF Software (United S...
The Apple Evangelist is responsible for building and cultivating strategic relationships with Apple 's small and mid-market business development field teams. This Read more
*Apple* Solutions Consultant - APPLE (United...
Job Summary As an Apple Solutions Consultant, you'll be the link between our future customers and our products. You'll showcase your entrepreneurial spirit as you Read more
*Apple* Professional Learning Specialist - A...
Job Summary The Apple Professional Learning Specialist is a full-time position for one year with Apple in the Phoenix, AZ area. This position requires a high Read more
*Apple* Picker - Apple Hill Orchard (United...
Apple Hill Orchard, Co. Rte. 21,Whitehall, NY 9/7/16-10/228/16. Pick fresh market or processing apples Productivity of 60 boxes and 80 boxes processing fruit per Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.