It is, and has been for a long time. Just move on. In fact, not even sure why I came back recently. Very few people here are actually interested in real facts, too many of them are slanted towards RMS crazy land. *pssst, I hate cell phones, they are used to track you and will remotely spy on everyone. Oh, can I borrow yours to make a call?*

Processing power still matters today. With the shift to more and more mobile computing platforms (lighter laptops, advanced smartphones, tablets), efficiency keeps us from needing to plug in as often. Also if you have a view of wanting to help the environment, it's less power wasted.

Keep in mind any Airplay compatible device can use ALAC, but can't use FLAC. This includes the Airport Express units that have been out since ~2004 or so, and the newer non Apple devices with Airplay compatibility. This is likely a move to assist with 3rd parties wanting to integrate more with Airplay, as the relevant network pieces (Bonjour) are already out there in source form.

Sadly I'm sure most people here will go on and on about how it's not FLAC, and whatever. For once, just at least appreciate that Apple is continuing to throw some interesting things out to the OSS crowd instead of deciding to nitpick it to death. If you don't want to use it, thats fine. Just really tired of the nitpickery and general negative outlook geeks around here tend to have. Cheer up for once :-)

If you don't have contact entries specifically labeled "Mom" "Brother" etc, then yes, you need to provide this information somehow. Either by telling Siri once, or by editing the address book.

(Reply written before most other posts, was distracted by work, going to post anyhow even with some now redundant info. Hope it helps.)

Android's voice recognition is mostly a search input box, driven by voice instead of text. It's pretty clever how Google built the system, they used voice input from the old GOOG411 number to help adapt it to different languages and accents. For the most part though, it will parse what you say and do the equivalent of "I'm Feeling Lucky" on google.com.

It also does dictation for typing in notes, or other apps. Basically anywhere the keyboard will appear, voice can be used as a dictation input.

Siri is a step beyond what Google offers, due to the conversational style of input vs just basic voice commands/dictation. You can say "Joanne Moore is my mother" to Siri once. Later, saying "Text Mom that I'll be late for dinner", and Siri remembers mom = Joanne Moore, or whoever. This just scratches the surface, the other power of Siri is the capability to understand questions like "Do I need a raincoat today?". It turns that into a search of the weather at the current location, scanning the days forecast for the possibility of rain. A followup of "what about Saturday?" would cause Siri to recognize this is a followup request, and it would link it to the previous weather query. The logic is in the Siri system, not in a search engine being queried. Minor detail, and either approach can work.

Google can improve their services on Android by improving what Google.com does, and this benefitting web users as well. For Apple, they have to decide what services to tie into. Many queries in Siri are farmed out to Wolfram Alpha. http://en.wikipedia.org/wiki/Siri_(software) has more info on other services it integrates with to try and answer questions. If none of those work, it defaults to running a web search similar to Android.

*sigh* Ok, let me try to explain this more carefully for you.

A user with an iPod Touch (a device that has a WiFi radio that can detect WiFi base stations, and also use one for internet access, but no GPS chip at all) is joined to an open network at a convention. He opens Google Maps, pulling in data tiles for the area nearby, and these get cached to the devices flash memory. Also cached to the device flash memory are the latitude and longitude of all the base stations in the area, say for a 2 mile radius (just as an example).

The user then walks away from the convention center, and the iPod drops off the open WiFi network, thus the device has no active data connection. It does however have the cached map tiles, and information about other WiFi networks. Using triangulation, the iPod can still place a blue location dot on a map drawn from the cached tiles saved earlier. It's not as accurate as GPS, but possibly good enough, especially if on foot. The more WiFi access points it can see, even if they are secured, gives the device more reference points to calculate location.

Along the way, the user takes a photo of something interesting. Due to the cached WiFi data, the photo ends up having pretty accurate latitude and longitude information added to the EXIF data, assuming the user enables geotagging of their photos.

Thats the part about why this cache is useful for the iPod Touch and iPads with WiFi only, with no 3G or GPS chips inside.

Now, the second part, why not use the device saying "I'm here". I'm assuming you mean the GPS chip. A pure GPS system takes a while to lock onto a users location from a cold start, and even a warm start can take a while. GPS chips also consume a decent bit of power, especially during cold start situations and while trying to obtain a positive position lock. One way to accelerate a lock is to already have a rough idea of where the device is. This speeds up the lock as it can then figure out what the GPS constellation looks like currently, and pick up the right signals to then get a better position. I'm not going to go too in depth on how GPS works, as Wikipedia can fill you in there.

The basic point is that GPS takes a lot of power, WiFi scanning takes less power, and cell tower scanning is even less power (due to the phone already having to keep track of towers to make sure the phone part works). Using cell tower triangulation results in a pretty poor location result, due to the low density of towers. WiFi positioning can be far more accurate, due to the smaller radius of the signal, and the higher density in most cities. And GPS gives the best location since thats what it was designed to do. By balancing all three and using cached data, you can provide a user useful location information quickly, without causing too much power draw or data consumption (counting against monthly quotas, and adding latency to the location calculation).

Timestamps on any cached data serve to indicate how old it is, so that the program can decide if it's time to attempt a refresh due to the data possibly being too stale.

And more then the last few data points are for the reason Apple gave at WWDC. It's for their iOS devices that don't have constant data connections like the iPod Touch.

Don't get me wrong, I see the potential privacy issues here if my phone was lost and someone rooted around in it, and I do think this situation could be addressed to still provide the same offline benefits without the risk. I'm going to dig deeper on it this weekend, just to see how they pull down the WiFi points in particular. I want to see if searching for something in a location far away ends up causing Apple to cache WiFi points even if I haven't personally visited the area, or if it only seeds them around the location of the device.

It's possible to do it both ways. Contracts do exist for most European countries as an option, along with subsidized phones.

And sure, it's possible in the US to buy a phone then pick service, but it's a pain. Between your mentioned T-Mobile 3G issue, and the lack of price incentives with AT&T on unsubsidized plans, it's not much of a choice.

And while I don't see the GSM vs CDMA thing as an anti-consumer conspiracy, I do find it might annoying. It would have been nice to see the FCC step in and guide the market towards one standard back in the early days. By having the split setups, it's impossible for nearly every phone to roam onto another network for emergencies. One standard would have allowed the carriers to cover the landmass easier, by signing roaming agreements to cover the areas they don't specifically cover with their own equipment. Some roaming agreements do exist today between the compatible carriers, but it's far from being as good as it could be.

Thankfully the future may get better in this regard. Verizon is transitioning to LTE now, as is AT&T, and many other smaller providers. Once Verizon supports voice over LTE, then maybe we can start moving more towards the situation the EU areas have.

True, just a shame it's not as widespread or easy as it is in Europe. When I visited in 2004, I was in and out of a cell phone store in 5 minutes. Bought a package that came with a SIM, and an ATM card. If I put the ATM card in, I could then add minutes by then inserting my bank card to charge it against.

SIM worked fine in my T-Mobile, unlocked US T610i phone.

The Android cache is not limited to 24-48 hours. It's limited by 50 cell towers for the cell database, and 200 for the wifi database. The time is how long the phone will trust a cached entry before querying for it again. At least according to the particular source code that was examined. Someone said it's not in the open side of Android anymore, but I haven't had time to confirm that either way, and at what point it was closed if it was.

The reason the cache exists on both iPhone, Android, and likely every A-GPS equipped device is the A part. Assisted GPS uses the known locations of cell towers (and recently WiFi hotspots) to help seed the real GPS part with rough location data to enable a quicker lock. The data in the caches on both Android and iOS are latitude and longitude locations of the towers, not the device.

Why is the cache a good idea? For the same reason any cache is. In this exact case, the phone doesn't have to use a data connection every time it seeds the GPS to look up coordinates for a tower. Reduces latency for cached lookups, lower power usage due to a skipped radio transmission, and lower data usage overall.

And as I explained in other posts, Apple already talked about their other use for the cache at WWDC 2010. Since not all of their devices have A-GPS or 3G data connections, the cache is helpful to enable those devices to still geotag photos and provide basic location info while away from a data source (such as being out and about not hooked into a WiFi network). The Maps program on the phone intentionally seeds the cache with WiFi access point info for the surrounding area to enable offline use.

This particular file isn't sent back to Apple, since all it contains is data provided from Apple already.

The reason the cache exists was explained at WWDC 2010 (and possibly before). Keep in mind that not all iOS devices are cell phones, and some lack 3G data entirely, along with GPS chips. If you have Location Services turned on with an iPod Touch, and do searches in Maps, Apple sends down WiFi location data as part of the request to populate the cache. The idea is that even though an iPod touch lacks a dedicated GPS, it could still function well enough to geotag photos (again only if people opt in), or navigate away from a conference center to some restaurant nearby.

From WWDC 2010, the purpose of the cache is for offline use, and to minimize network calls. Since it's the same code on both iPhone, iPod Touches, and iPads, the WiFi part in particular is important, since not all the devices may have 3G data connections at all times. The example they gave at the presentation was an iPod touch user pulling out his device while at the conference and locating a nearby restaurant using the free WiFi there. By searching in an area, Apple also sends down the relevant WiFi access points in the area to feed into the cache. When the user leaves the conference center and drops off the data network, the Maps program can still show a pretty accurate location, allowing the person to navigate to the restaurant. If he takes any photos or video along the way, it's all geotagged too if the user enabled that feature.

For Android, (and likely every other phone with AGPS) the cache is there to minimize the times the phone has to go and ask over the data network to get the initial seed data for the real GPS. Apple took it a little father to also help out their GPS lacking devices.

No, it should be buy a phone, then buy service, like the Europeans have. One phone works on all their providers, and thus the providers have to actually be competitive on rates and service, since they can't use unique phones to attract business.

Also, Verizon iPhones are not eating AT&T's lunch yet. From the Q1 quarterly reports:
Verizon: 2.2 million iPhones activated
AT&T: 3.2 million iPhones activated

Verizon activations are all new iPhones. AT&Ts numbers do include used iPhones being activated on new accounts too so it's hard to say exactly how much a hit AT&T is seeing. So far it doesn't look like much. Odds are AT&Ts growth will slow a little but, but not at the same exact percent as iPhones rise on Verizon. Most people will wait out their contracts on either network before making a big change. For Verizon that change could also include Android owners who bought an "iPhone like" phone, and then get the proper Verizon iPhone later.

I think educating people about this is good, but it should also be clear that this isn't the default on all platforms. The iPhone for example specifically asks when a user uses the camera if they want to allow the camera program access to the users location. In iOS 4, this was expanded to also provide information right on the prompt about why this info was requested. On or off is presented equally. It's the users choice to geotag photos on the iPhone, and that choice can be changed at any time. From what I understand, other platforms are similar.

iPhoto on the Mac will also default to stripping location data before exporting the photos anywhere. This includes both publishing the photos online, or exporting them to a folder outside the iPhoto data store.