Fresh Apple: TheAppleBlog (6 сообщений)

rss2email.ru

На пути к Успеху!

Новый подход к e-mail и SMS-маркетингу

YESWAY.RU -необычное красивое интересное

Вишневые креветки в домашнем аквариуме

TheAppleBlog
News, reviews, walkthroughs, and real-life application of Apple products
http://theappleblog.com
рекомендовать друзьям >>

Big Changes Ahead for Apple TV
Apple TV looked about ready for the dustbin in recent years, especially with great free media center PC alternatives available like Boxee and XBMC. And with the recent announcement of Google TV, it sure looked like Apple’s foray into the dedicated home entertainment industry was pretty much done for. Not so, according to a report by Engadget.

A tipster, whose story has also been confirmed by another source very close to Apple, tells the gadget blog all about the next iteration of the Apple TV. And it’s not what you might expect. Instead of an incremental update (more storage, better output, etc.) the Apple TV will undergo a complete overhaul, and in the end won’t look much like the device people have come to know (and possibly, though not likely, love).

The next iteration of Apple TV will actually build on Apple’s strength as a mobile device company, by being, essentially, a mobile device. If the tipster and the collaborating source are correct, the new device will be based on the iPhone 4, including the A4 CPU and only 16GB of internal storage. It’ll support full HD 1080p output using those guts, though, so don’t get too worried. And it’ll also depend more on the cloud than on local storage for delivering content.
More on iPad
It’s being described as an “iPhone without the screen” and should only have two or three ports (video out and power). And what will you pay for this mighty mini machine? $99. That’s it. If the price point is true, then it’ll definitely give Google a run for its money. Especially if it runs iPhone OS and is as portable as it appears to be. Imagine being able to take all your TV content with you wherever you travel. Quite the proposition.

Despite the move towards streaming and away from local content, you’ll be able to use a Time Capsule as an external storage device, so all those movies and shows you’ve downloaded won’t be for naught. iPhone and iPad app integration is a definite possibility, and one that has my heart racing. Finally I can play Warpgate on a screen where I can actually make out the details of the starships! That’s provided Apple adds support to the iPhone SDK for upscaling, which I hope it will. And Scrabble with iPhones and iPads combined with the Apple TV, anyone?

This is shaping up to be the perfect storm of tech convergence within a company. Throw in some official support for a Boxee app on this device, Apple, and you’ve got a guaranteed customer right here. No word on when it will arrive, but let’s cross our fingers for a WWDC mention or two.

For those interested in cloud computing or data centers, check out our Structure conference in June.

Переслать
TechUniversity Freebie: Creating Chiptunes with GarageBand
Take yourself back to a simpler time when video games had fewer colors and their soundtracks were made up of bleeps and bloops!

We’ll show you how to create an 8-bit video game sound (called a “chiptune”) out of any midi track using GarageBand and the Magical 8bit Plug.

This TechUniversity screencast is completely free! Just head on over to TechUniversity to check out the full video.

Here’s a short sample for you as well…

Переслать
iPad Mania Begins as iPad Launches Internationally
Apple’s iPad is now available internationally, a full 53 days after its original U.S. debut.

This Friday morning early adopters around the world queued up in a bid to get their hands on the long-awaited tablet device. Many of Apple’s retail stores decided to open an hour earlier than usual. The doors opened as planned, ready to serve the scores of awaiting anticipated Apple shoppers that had formed queues from the very early hours of the morning.

Shoppers in Australia, Canada, France, Germany, Italy, Japan, Spain, Switzerland and the UK can now get their hands on the device. In the UK a basic 16GB Wi-Fi model can be picked up for £429.99, the same model is priced at $549 for Canadian customers, whereas German consumers can grab a new iPad from €499. More international pricing details for the iPad can be found on your country’s Apple store website.

For those not in the countries outlined above, Apple has detailed that more countries will receive the 9.7-inch device at some unknown point in July. Today’s more widespread global availability comes after Apple had to delay the international launch due to the overwhelming debut the tablet enjoyed in the U.S..

Reports regarding the tablet’s global launch have started to roll-in, detailing the reception Apple’s device has garnered. Several hundred people were queuing outside Apple’s flagship UK store according to UK tech publication The Register. Similar scenes were reported at Spain’s Munich store, where 9to5Mac described the launch event as manic. Apple fans in Japan apparently started queuing days in advance according to a TUAW report.

Following today’s global launch Steve Jobs will no doubt detail how the international launch fared at the upcoming WWDC next month with some early sales figures.

Related GigaOM Pro Research: Hot Topic: Apple’s iPad

Переслать
iPhone Dev Sessions: Responsive Web-Enabled iPhone Apps
Back in August 2009, Shufflegazine featured an article talking about what makes a good iPhone app. The article has a good discussion about what apps are popular and why, and ultimately concludes that a good app has to be simple, intuitive, responsive, and give users a compelling reason to use it.

Unfortunately, there's no recipe for how to write a simple, intuitive and compelling app. Our best bet for getting our hands on that recipe is probably this guy, but until he makes that announcement, handling these points is left as an exercise for the reader.

Writing a responsive app, however, is much easier.

A good working definition for a "responsive" app is one that responds to user input quickly and doesn't hang without telling the user what's going on. The rule of thumb here is that GUIs should respond to input in no more than 1 second, so the bar is set pretty high, especially for web-enabled apps. This article describes the most common reason GUIs get unresponsive and what to do about it.

How Do These Newfangled GUIs Work, Again?

Cocoa Touch's GUI (like most GUIs) is built on an "event + event loop" architecture. User interactions like taps and keypresses are translated to events, and these events are then processed one-by-one in the imaginatively named event loop:

Simplified Event Flow in a Cocoa App

As long as each event gets processed quickly, the GUI stays nice and zippy. But because events are processed serially, one event can back up the whole gravy train. If one event takes five second to process, then the GUI will be completely unresponsive for those five seconds until the event loop can start processing new events again.

But what if you have some GUI resources that take five seconds to load? We can't load them all at app initialization time because we don't always know what resources we'll need when the app is starting up, especially for things like profile pictures. Also, the iPhone is an embedded platform, so memory for preloading is in short supply, anyway. How, then, can we appease the event loop tiki gods? The answer, young grasshopper, is to load such resources asynchronously, and then update the GUI when they're done loading.

Responsiveness Test Bench

To illustrate these ideas, I've made a simple iPhone app that loads an image resource for display in an iPhone app GUI three different ways.

The Responsiveness Tester. The people responsible for the appearance of this iPhone app have been sacked.

Each method loads and displays the same image, but does the loading differently to demonstrate the effect each approach has on GUI responsiveness. The source code for this app is attached to this article if you'd like to play along at home.

When the user chooses a loading technique by tapping its table row, a corresponding method is called to illustrate that loading technique. These methods are called directly from the UITableViewDelegate tableView:didSelectRowAtIndexPath: method, which runs in the event loop, so all this code runs directly in the GUI thread.

First, let's have a look at the code from the load-from-file example:
```
 - (void)showSynchFileDemoWithTitle:(NSString *)title {     UIImage *image;     image = [UIImage imageNamed:@"apple-logo.png"];     EagerViewController *view=[[EagerViewController alloc]         initWithNibName:@"EagerViewController" bundle:nil title:title image:image];     [self.navigationController pushViewController:view animated:YES];     [view release]; } 
```
The code looks like it sounds, right? We load the image from disk, use it to create a new UIViewController, push that UIViewController onto our UINavigationController, and then release the UIViewController back into the wild. This is exactly why synchronous loading is so popular: it's ridiculously simple. And since we're just loading a small image from a file, the GUI is still zippy, so synchronous loading is actually fine here.

Now let's look at loading that same image from a synchronous web request instead of a file:
```
 - (void)showSynchWebDemoWithTitle:(NSString *)title {     UIImage *image;      NSURLRequest  *request=[NSURLRequest requestWithURL:[NSURL         URLWithString:IMAGEURL]];     NSURLResponse *response=nil;     NSError *error=nil;     NSData *content=[NSURLConnection sendSynchronousRequest:request         returningResponse:&response error:&error];     if(content == nil)         image = [UIImage imageNamed:@"big-red-x.png"];     else         image = [UIImage imageWithData:content];      EagerViewController *view=[[EagerViewController alloc]         initWithNibName:@"EagerViewController" bundle:nil title:title image:image];     [self.navigationController pushViewController:view animated:YES];     [view release]; } 
```
The code is slightly more complicated, but still not too bad. We set up a web request for the image, wait for it to download, build an image with the contents of that request if it succeeded or load a default image if it failed, and then build our UIViewController from that image. Still nice and easy, but how does it perform?

The problem with synchronous web loading. Hang much?

Turns out, not so well. After the user taps "Synchronous from Web," the app just kind of sits there for a few seconds before it shows the next view. Why? The synchronous web request loading the image in the event loop takes a while to complete, which blocks the event loop and hangs the GUI. This kind of code is surprisingly common despite the hangs it causes. Unless you're willing to tick off your customers, which is usually considered harmful, synchronous web loading in the event loop is right out.

So what's the asynchronous web loading equivalent look like? Behold, ye mortals, and despair…

From RootViewController.m:
```
 - (void)showAsynchWebDemoWithTitle:(NSString *)title {     LazyViewController *view=[[LazyViewController alloc]         initWithNibNamed:@"LazyViewController" bundle:nil title:title         imageURL:[NSURL URLWithString:IMAGEURL]];     [self.navigationController pushViewController:view animated:YES];     [view release]; } 
```
From LazyViewController.m:
```
 - (id)initWithNibNamed:(NSString *)nibNameOrNil bundle:(NSBundle *)nibBundleOrNil title:(NSString *)title imageURL:(NSURL *)imageURL {     if(self = [super initWithNibName:nibNameOrNil bundle:nibBundleOrNil]) {         self.navigationItem.title = title;         if(imageURL != nil) {             self.getlogo = [AtomicAsynchronousWebRequest requestWithURL:imageURL                 andDelegate:self];         }     }     return self; }  - (void)updateLogoWithImage:(UIImage *)image {     [self.logo stopLoadingWithActiveView:[[[UIImageView alloc] initWithImage:image]         autorelease]]; }  - (void) atomicAsynchronousWebRequest:(AtomicAsynchronousWebRequest *)request didFailWithError:(NSError *)error {     if(request == self.getlogo) {         [self updateLogoWithImage:[UIImage imageNamed:@"big-red-x.png"]];         self.getlogo = nil;     }     else {         // We have no idea which request this is. Just log it and move on.         NSLog(@"Failed unrecognized HTTP request: %@", request);     } }  - (void)atomicAsynchronousWebRequest:(AtomicAsynchronousWebRequest *)request didSucceedWithResponse:(NSURLResponse *)response andContent:(NSData *)content {     if(request == self.getlogo) {         [self updateLogoWithImage:[UIImage imageWithData:content]];         self.getlogo = nil;     }     else {         // We have no idea which request this is. Just log it and move on.         NSLog(@"Succeeded unrecognized HTTP request: %@", request);     } } 
```
Oh… that's all? Well, I guess that's not so bad. We pass the URL for our image to the UIViewController initializer, and the UIViewController then starts an asynchronous web request for the image and updates the logo view with an image when the web request either succeeds or fails. (Observant readers will notice some custom methods above. Hang tight, we'll talk about those in a minute.) What does all this trouble buy us?

Nice and Zippy. Asynchronous Loading FTW!

A wonderfully responsive app, that's what. The transition from the first view to the second view is instantaneous; the second view shows its spinner until the web request completes or fails, and then the logo is updated with a new image. Why is this UI so snappy? Because all long-running operations are performed outside the message loop, so nothing hangs the GUI thread. Lazy loading for slow resources is clearly the way to go.

And if you think about it, this approach is good not only because it runs faster, but also because it's more modular. The UIViewController being created knows what it's displaying; it should probably be loading its resources too, especially if that loading is complex, in case that UIViewController needs to be reused elsewhere in the app.

So… sweet. A twofer.

Being Lazy About Being Lazy

If asynchronous loading is what we need to be doing — and it is – then how can we make it easy? It turns out that asynchronous loading is easier in Objective-C than it is in many other languages.

In Java, for example, asynchronous loading requires you to mess with callbacks and Threads, SwingWorkers, or ExecutorServices, which feels like jumping through a bunch of flaming hoops while wearing a newspaper tutu. In Objective-C, though, web requests are baked into the API and already have asynchronous callback functionality, which means that asynchronous loading can be had essentially for free, especially if we do a little customization of our own.

The app uses two custom classes. I'll discuss them here just in case the classes themselves or what they do is useful to other developers. Both classes are in the attached source if you want to put your eyes on them, or use them for your own nefarious purpose.

AtomicAsynchronousWebRequest

The iPhone SDK's generalized web request API is NSURLConnection, and you can find a good primer on how to use it here. The NSURLConnection exposes way more features than most apps need, though, like hooks for reacting to redirects and chunked input, which makes it more difficult to use than it needs to be. AtomicAsynchronousWebRequest is a thin wrapper around NSURLConnection that lets developers perform the most common web tasks (namely atomic GETs and POSTs) asynchronously by implementing a dead-simple 2-method protocol.

DelayedLoadView

While the iPhone has a nice "spinner" GUI element (UIActivityIndicatorView) that's handy for telling the user something is loading, it has no explicit API for populating GUI views lazily. DelayedLoadView is essentially a "container" view that shows a spinner until it's updated with its "real" content view, which makes handling activity indicators and lazy content really easy, especially for GUIs built-in Interface Builder.

Gotchas

A couple gotchas have been glossed over in the interest of keeping things at least a little brief. Now that we're past the good stuff, I'll mention a few of them here, just in case you want to get creative on your own:
1. All GUI updates must happen on the GUI thread. Cocoa Touch GUI elements, like GUI elements in most toolkits, are not thread-safe. So, if you need to interact with a GUI element, you need to do it from the main thread. If you're not making your own threads, you probably don't need to worry about this. If you are, you may need to make use of NSObject's performSelectorOnMainThread:withObject:waitUntilDone: or similar.
2. Remember that UIViewController IBOutlets are not initialized after super's initializer completes. Instead, the UIViewController must be set to appear before IBOutlets are properly connected. This means that failure conditions can't really be handled inside a UIViewController initializer, so any custom load code you write needs to take that into account. If you want an example of how to work around this issue, check how AtomicAsynchronousWebRequest calls its failure method from its initializer roundabouts using a performSelector call.
3. UIActivityIndicatorViews are kind of confusing. You probably want to set hidesWhenStopped to YES. That way, startAnimating and stopAnimating will do what you expect them to. If you don't see a spinner and you expect to, make sure your UIActivityIndicatorView isn't hidden. If you see a spinner but it's not spinning, you need to call startAnimating.
4. Not all long-running operations have asynchronous callbacks baked in. Web requests do, which is very handy, but if you need to do some other kind of loading you'll have to get creative. If you're only going to load things now and then, using performSelectorInBackground:withObject: is probably just fine. If you're going to be doing a lot of loading, though, you won't want to create a new background thread each time you load something, so you'll probably want to create a custom NSRunLoop and kick off your loading with performSelector:onThread:withObject:waitUntilDone:. You can synch up the GUI when loading's done with a simple performSelectorOnMainThread:withObject:waitUntilDone:.
Conclusion

You're now an expert on how to build responsive network-enabled GUIs! Or at least you know more than you did.

It's worth mentioning that even though the article focused on loading images, the very same principles can be applied to executing web service calls, loading web pages, or any other task that requires time to complete.

I now expect all apps to have responsive GUIs, even if they're loading resources from the web. You've been warned. I've got my eye on you, iPhone developers.

Stay QWERTY, my friends.

Переслать
TechUniversity: Advanced Image Editing with Keynote
Many users have Keynote, part of Apple’s iWork suite, but don’t have (or even need) an image editing application like Photoshop. Thankfully, Keynote has image editing capabilities built-in as part of the application! We’ll show you how to use these tools to make both minor and major image adjustments in this TechUniversity screencast on image editing in Keynote! (subscription required)

Topics covered:
- Image masking and cropping
- Adjustments: Brightness, Contrast, Exposure, Saturation and more
- Instant Alpha
- Power user tips
Below is a sample of the video. The full screencast clocks in at just over 10 minutes.

Переслать
Apple Overtakes Microsoft in Market Value: End of an Era?
Apple, for a long time, was the David to Microsoft’s Goliath. It was a dynamic that suited Apple, as the company used its underdog status to attract customers who saw themselves as different and apart from the mainstream. It was the iPod that first signaled a change in this arrangement.

The iPod dominated. It became synonymous with “MP3 player” in the mind of the buying public. And that would start in motion the rise of Apple into the tech giant it is today. A tech giant, might I add, that as of yesterday is worth more in terms of market value than Microsoft.

At the close of Wednesday’s trading, Apple was valued at $222 billion, while Microsoft was worth $219 billion. Apple’s shares ended the day at $244.11, while Microsoft’s finished at a seven-month low of $25.01. And it isn’t only Cupertino’s successes, but also Redmond’s failures that are responsible for the new power dynamic between the two companies. Overall, Microsoft stock is down 20 percent compared to 10 years ago, while the value of Apple’s has grown tenfold over the same period.

Microsoft CEO Steve Ballmer appears to have his head in the sand regarding the significance of this moment in terms of the two companies. When asked for comment, he told Reuters news service:

It’s a long game, we have good competitors…we too are a very good competitor. We are executing very well and that is going to lead to great products and great success. I’m optimistic.

It sounds like Ballmer, once an outspoken and not very cautious CEO, has checked out, or is downright unwilling to look at the consequences of Apple’s success with the iPhone and now the iPad. Microsoft will continue to drift toward irrelevance as long as the attitude of business-as-usual prevails there. To quote Ballmer once again, “I won’t predict some massive change,” he said. “I don’t sort of foreshadow any change in direction. We just have to accelerate plans.”

I’m less concerned with what happens to Microsoft now, though, then I am with what happens to Apple. Unlike Microsoft, I think Apple has at its core a commitment to ongoing innovation, woven into the very fabric of the company by the strong oversight of Steve Jobs. And that will persist after he’s gone. But ongoing battles with Google and Adobe tell a tale of a company whose industry agenda may still be geared towards being a niche player.

Apple is about control, even though Steve Jobs says quite the opposite in his open letter to Flash. Don’t get me wrong, I’m no big fan of Flash myself, but I do think that Apple’s intentions have more to do with controlling the nature and delivery vehicle of content than with encouraging openness. Otherwise it’d have backed Google’s VP8 open web video standard from the start. The kind of control Apple exerts works well for it as a niche player, but now that it’s arguably the most important tech company in the world, the same rules don’t apply.

Big stays big by being inclusive and cooperative, to a degree. Take Google, which works with so many partners it’s hard to keep track of, with the end goal of satisfied customers in mind. Microsoft, too, works with others more than it shuts them down, as long as the terms are favorable. Apple seems content to remain largely sheltered, even when it would be easier and more expedient to work with a partner. In fact, since the company started making its own chips with the iPad, it looks to be shutting down even further still.

Such an approach may provide some short-term gains, but rising competitors like Google will take advantage of the general bad feeling it will generate among other tech firms to form the kind of partnerships that helped elevate Microsoft to its loftiest heights 10 years ago. And Apple will still be at base camp, stubbornly refusing the aid of other climbers.

Related GigaOM Pro Research: How Microsoft Can Win Back the Tablet Market

Переслать