Results tagged “iPad” from Bill's Words

iOS 6 added a Reminders app, and I use it in spite of the awful interface. (The “on/off” switches for “Remind Me On a Day” and “Remind Me At a Place” are particularly awkward, and why doesn’t checking off a task make it go away?)

I have a daily reminder at 7:30pm to remind me about a task. Sometimes I do it early and check it off as being done. (Yay, me!) Strangely, reminders then reminds me at 7:30 that same night to do the task… and shows it as needing to be done at 7:30 tomorrow. It also shows up in the Reminders list as needing to be done at 7:30pm tomorrow, though it just reminded me about it at 7:30pm today.

Yes, a bug. An annoying bug.

Update: I can’t reproduce the bug. So I’ll delete my event and hopefully that’ll solve the problem.

When we last left our intrepid hero, he had just replaced the digitizer on his new-to-him iPad 2 with a brand-new digitizer, but had managed to make a mess of the display and somehow killed the sleep button. In this part of the story, our hero has ordered a replacement power button/mute switch/volume button flex assembly from somebody on eBay (iParts2, to be specific) and a batch of new adhesive bits to stick the display back on once the flex assembly was replaced.

At this point in the story, our hero drops out of speaking in the third person because it sounds so much like Facebook of a few years ago and because it’s a little too impersonal, even for me.

The only problem with the non-Apple part I ordered is that it doesn’t come with all of the same adhesive strips that the real Apple part would have. It does have the ones which are most important, though, and that’s what mattered. The buttons’ locator pegs were a bit iffy, but the buttons stayed where they are supposed to, and the part was less than three measly bucks, so I won’t complain.

Installation was pretty straightforward, if a bit nerve-wracking. This job is not for the faint of heart since you have to remove a PCB assembly from the depths of the iPad. That PCB has to come out in order to remove some tape and free the flex connector. You also have to remove the rear camera and other bits for a total of about a dozen screws. Keeping your kids and pets away from your neatly-ordered screws and parts is a good idea. iFixit has a wonderfully-clever magnetic mat which they sell just to hold the itty-bitty parts. Better yet, they’re including it for free with their big set of tools for Black Friday weekend, so go get it now while you can. (Mom? Dad? Christmas is coming soon.)

The instructions for replacing this flex assembly can be found here at iFixit. All I can add to the instructions is for you to take a picture of the way in which the cable runs around the top corner of the iPad. The closeups of the corner don’t show that routing well enough and I sorta’ made up the routing on my own. Here’s hoping that it works.

And if the plastic clip shown in Step 3 (“no mover” sic) should come out, don’t panic. Getting it back in isn’t too difficult. To get it back into place, use a small spudger to hold the button horizontal while you hold the bail with a pair of needle-nose pliers. What you’re trying to accomplish is to push the button away from the bail and hold the bail back with the pliers as you guide the assembly into its hole. Video would help here, but I’m not gonna’ take that thing apart again…

The repair of the cable was a total success. Until the very end, that is, when I was pressing the digitizer back onto the iPad and cracked it.

Sigh…

New digitizer is on the way, and I’ve learned just about all the lessons involved in doing a digitizer transplant. I hope I don’t find anything else to teach you, and I’ll be sure to update you on how the (hopefully) final repair goes.

It was going well until the very, very end.

I had almost (yes, almost) successfully replaced my new-to-me iPad 2’s not-so-badly-cracked digitizer, a.k.a. “touchscreen.” I learned a few things along the way, which I present here for you to use at your own risk:

• It is damned-near impossible to remove the first iPad 2 screen you ever remove without breaking something. What you are doing, after all, is removing a tightly-glued thin piece of glass from the remainder of the iPad by bending the rest of the iPad away from the glass to get it started. The best way to do this is to use a flat but very stiff (putty knife stiff) plastic tool about 1/2" wide. Heat the glue as directed elsewhere and then place the edge of the tool just inside the plastic rim around the screen. Push straight down hard and you’ll bend the aluminum away from the display glass just a smidgen—just enough to rotate the tool into the gap you opened up. Once you do that, follow instructions elsewhere to remove the display in one piece. Mine did not come off in one piece.

• This tool might be ideal.

• Use a shop towel to work on. They’re soft enough, but cheap enough to throw away because you’re never going to get all of those sticky little glass shards off it. Work for a while until you gum up one, throw it away, get another, and continue. You won’t scratch the back of your iPad this way.

• Apparently, it’s really, really easy to damage the power button cable. My power button (sleep button?) doesn’t work now. That’s where the “almost” above comes from.

• You’ll get dust in between the glass and the LCD. I did the job as perfectly as I could and I still had dust in the way. The solution is to use canned air (or whatever they’re passing off as air these days) and to leave a bit of the digitizer lifted before sealing it up. Stick the straw into the corner of the display and simply blow the dust into the far edge of the digitizer. If you think about it ahead of time, you can probably dust things off before assembly.

It was in the process of dusting the display from the inside as I mention above that I messed things up. Instead of keeping the can upright, I turned it upside down accidentally. Did you know that what’s in the can is not air, that it’s actually liquid? Yeah, I knew that too, and the resulting mess inside my iPad proved it to me. Now I have a huge smudge caused by the liquid—plus condensation! w00t!—in between the LCD and the digitizer.

To fix this problem, I’ve ordered new adhesive and a new power cable. I figure that the slightly less-than-optimal adhesion, plus my newly-found digitizer removal skillz may mean I won’t have to order a new digitizer. Worst case, I order another digitizer, which I can afford to do about (hmmm… borrow… carry the one…) six more times before I would have been better off taking the thing to Apple.

I’ll report back…

Representing weather data as an image is only part of the magic behind the scenes:

The reason we encode velocity data as an image is so we can pass it off to the GPU on the iPhone and iPad. Both the storm prediction and the smooth animations are calculated on the device itself, rather than the server, and all the magic happens directly on the GPU.

Read the rest of the article here.

via SplatF

People arguing in the subject post that the iPad is not a PC use the following (in my opinion) specious arguments:

• It will confuse people.

Useless argument. People can be taught, and they’ll learn that tablets are PCs as soon as you guys agree that they are.

• Smartfridges will be classified as PCs, as will digital watches, smartphones, etc.

No, they won’t. The primary purpose of the PC is… nothing in particular. That’s why the Xbox and Nintendo DS are also not PCs. And neither is a smartphone.

• Tablets are used only for a limited set of uses which look a lot like a portal to the Internet.

OK, but what do most people use their definitively-classified-as-PCs PCs for?

The iPad—and all other tablets—are PCs. Now, can we get on to something more useful, like arguing about how well Madonna did last night?

Chart here.

It makes me wonder, though, if there’s a breakfast/lunch/dinner rush at the App Store, though.

I’ll add only one thing: iPads do not do quite as well in the bathroom as magazines do, though they do prevent the flurry of those stupid subscription cards that comes with the arrival of each new Car and Driver.

Here’s how I read Apple’s response to the Lodsys letters and, not being a lawyer, it might be wrong:

1. Lodsys says that Apple is licensed to use the Lodsys patents in Apple-branded products. (And conversely, from Lodsys’s previous assertions, the developers are not licensed to use the Lodsys technologies in the developer-branded products.)
2. Apple says that the app developers’ products use Apple-branded products. I.e., if the developer uses an API, it’s an Apple API. If the developer uses an iOS device, it’s an Apple iOS device. And if the developer relies on the iTunes store, it’s the Apple iTunes store, etc. Apple even cites the letters that Lodsys uses to show infringement as showing Apple-branded products throughout.
3. Since the developers are using Apple-branded products to implement the technologies Lodsys claims to own, the Lodsys patent(s) are not being infringed upon, these Apple-branded and legally-licensed products having been legally sold to the App Makers (as Apple calls them). A Supreme Court reference is used to make it clear that that’s how Apple’s reading the claims, too.

Here’s a concrete example to help illustrate my reading: Let’s say you build FasterBikes bicycles and buy a Shimano drivetrain for your product. The Shimano drivetrain uses a gear technology licensed from another firm, Lodsys. By now, you would have received a letter from Lodsys telling you that you have to license their technology for use under the FasterBikes name. Shimano (Apple), however, having licensed the gear technology for use under the Shimano name, is essentially telling Lodsys in this letter that the Shimano-branded parts are still Shimano-branded parts and that they have no business trying to get FasterBikes to license the technology. If, on the other hand, you made your own drivetrain that used the Lodsys gear technology and put that on your bike, then Lodsys would have a leg to stand on and you’d be on your own.

And that brings me to this interesting thought: What about apps which are sold through Cydia, the jailbroken iOS device app store? I think Lodsys might have a leg to stand on there since those apps probably don’t use the Apple-branded APIs for certain activities and hence are not licensed to use the Lodsys technologies. And how about the apps sold through the Android Market? Though Google is a licensee of these patents, I don’t think the Android Market has in place any controls (read “curation like Apple does with the App Store”) which would prevent use of the Lodsys technologies through a non-Google-branded API.

In other words, maybe there is a good reason for Apple to collect its 30% for all purchases, and maybe there is a good reason for Apple to require the use of its APIs wherever possible: legal protection against the so-called “patent trolls.” For these developers, it seems to be worth the price so far.

Anywho… one commenter to Macworld put it pretty succinctly: “Wow that is the longest and most articulate bitch slap I have ever read.” It is not, however, a slam-dunk. I’m pretty certain that Lodsys won’t drop the notices and will try articulating their argument a different way—if they bother doing anything at all. After all, they have nothing to lose and everything to gain, and the only people who will lose in this are the individual developers. And in that case, for them the only hope is that Apple will file suit against Lodsys, since I don’t see anything criminal (i.e., the government won’t step in) in what Lodsys is doing.

At any rate, I think this one is going to get more interesting, so stay tuned!

The quick rundown: A company called Lodsys is threatening a handful of small developers with legal action for their supposed infringement of a Lodsys-owned patent by the developers’ use of Apple’s in-app purchasing system. Some developers are trying to get Apple to step in and help by boycotting the in-app purchasing system. The full story is here on ars technica.

Others in the community have opined that the patent in question is overly broad and would likely be invalidated at trial, but getting to trial and conducting individual trials is well beyond the budgets of these small developers. And so what we have here is reasonably similar to a protection racket, only it’s entirely legal.

In this particular case, it would be entirely reasonable for Apple to step in and attempt to invalidate the patent on behalf of the developers because, after all, part of Apple’s revenue stream is at risk. If developers choose not to use the in-app purchasing system because of the threat of being sued, then Apple doesn’t gain the revenues from that purchasing stream.

But let’s assume for a moment that Apple can’t or won’t get involved for some reason. Perhaps Apple legal thinks it’s a slippery slope and they will only end up shelling out many more millions than they stand to make on this revenue stream. Or let’s assume that another patent troll and patent were involved and it didn’t directly affect Apple’s revenue stream somehow, though it does affect the individual developers.

What then?

There aren’t a whole lot of options to developers. Unfortunately, unlike a criminal trial where the government is required to provide a defense to the accused, civil defendants have no such protections afforded them—they’re left to defend themselves at their own costs. At best, they might find someone who is willing to take the case pro bono (literally, “for good,” i.e., not “for money”). The Electronic Frontier Foundation, for example, has a staff of lawyers who help out sometimes in cases like this. But while the EFF is certainly no friend of patent trolls, I’d guess it’s also not likely to defend the closed and proprietary Apple ecosystem, either. And it’s highly unlikely that any really good intellectual property (IP) firm would undertake the defense of one small developer. It’s still about the almighty buck, and there wouldn’t be enough publicity in that.

So here’s my suggestion: Crowdsource the defense and gang up on Lodsys.

Step 1: Start a Kickstarter project to fund the evaluation of the validity of Lodsys’s claims. This has to be done quickly as the developers have only a few weeks to respond to Lodsys. It would certainly help if an intellectual property (IP) attorney with a superior track record in defense of IP claims were willing to do the work pro bono, but there will still be costs involved.

I, for one, would throw in $100 on principle alone.

Step 2: If indeed the patent looks unlikely to hold water, then continue with the Kickstarter project to consolidate the certain-to-occur litigation and see it through trial.

It’s a risky proposition, sure, because nothing’s certain in the Eastern District Court of Texas—the developers could still lose the case. But what message would it send to the patent trolls?

For one, it says that the little developer is no longer helpless. Sue enough of them, and you’ve kicked the hornets’ nest, so to speak. Second, it says that the patent in question had damned-well better hold water, and hold it well. (As much as I hate software patents, it’s the law, and if your product really does infringe, then you’re on the hook to license it. Sorry.) Third, it sets a precedent, and it’s all about setting precedent in law.

So… what about it? Anybody able to start a Kickstarter for this one? Any IP attorneys out there willing to give it a go?

I might have to back off my stance that Apple will bring out an iPad “retina display” that won’t be twice the resolution of the current iPad.

MacRumors reports that Samsung has developed just the LCD required for that (give or take a few pixels).

Sigh. And I thought I had excellent reasoning.

John Gruber and I have briefly conversed about what the resolution of an upgraded-resolution iPad will be. He firmly believes it will be 2x the current resolution because it’s just easier. (True, it is.) But I believe that some future revision of the iPad will have a higher-resolution display which is not a fixed integer multiple of the current resolution for reasons I’ve outlined previously. Two more things make me think I’m right.

First, Apple itself. With 10.4 and 10.5, resolution independence was introduced in phases and was “developer only.” (Via DaringFireball.net) 10.6 was supposed to be more resolution-independent than the previous two releases, but… alas, not so much. That’s bad.

Or… is it? Wouldn’t it be a convenient alignment of things if iOS 5 and Mac OS X 10.7 introduced resolution independence about the same time? They share the same rendering engines, after all, and many other parts of their architecture. If both OSs introduced the last bits of making their interfaces resolution independent, it would make good use of resources in the company. Not that Apple has to think frugally, but if they’re trying to converge the two platforms somehow…

I’m just sayin’.

Second, WebOS Enyo apparently does some resolution independent jiggery-pokery according to this Engadget note. Not that I understand exactly what this means, because I am not about to plunge into the WebOS SDK documentation, but they are making a concerted effort to attract developers by allowing devs to write once for multiple target resolutions. That’s powerful stuff.

Now, Apple does not promote that devs should write once for iPad and iPhone/iPod (because the interfaces themselves should really be tailored to the different screen sizes), though it does work. Instead, Apple would likely try the same approach as HP and promote resolution independence as the bridge between future higher-resolution devices and the past’s lower-resolution devices. WebOS is ahead of both Mac OS and iOS here—there’s some real competition, finally.

So that’s it. I further stick my neck out on the subject of the iPad X’s resolution.

I sure hope I’m right…

There’s been a lot of guessing about the resolution of the iPad 2. Everybody who has been speculating (except me, it seems) has been saying that in order for Apple to be happy with the product, they’ll have to call it a “Retina Display,” and that in order to do so, they’ll have to double the iPad’s 1024x768 resolution. That is, after all, what they did to the iPhone 3 to achieve Retina Display status for the iPhone 4.

Yes, this makes good sense for lots of good reasons, not the least of which is that graphics work better when the scaling factor is a nice, round two. And with the more-limited hardware of the iPhone, it makes a lot of sense. But as others have noted, that resolution would be a whole helluva’ lot of pixels to push, and that ain’t happening in the iPad. Not yet, anyway.

I, on the other hand, am guessing that Apple will choose something else and that there’s nothing special about “times two.” They’ll choose manufacturable, cost-effective, and, above all, marketable over “times two” any day. Technically, I believe “times x” is completely feasible as I outline in a previous entry, especially if the iPad 2 has more horsepower than an iPhone 4.

So I’ll guess that Apple will define “Retina Display” as it properly should be, i.e., they’ll base it on the resolving resolution of the human eye, and not on an arbitrary number of pixels “times two.”

The thing that most people miss in their guessing is that the average user doesn’t hold an iPad at one foot as she might with an iPhone 4. No, the typical iPhone user holds it at about 1.5’ to 2’—lap distance or so. If we start with Bryan Jones’ assertion that the eye can resolve about 287ppi at one foot and scale that triangle up to 1.5’, then the resolution required is only about 190ppi. Since the current resolution of the iPad as stated by Apple is 132ppi, then an iPad Retina Display would have a minimum of 1475x1106 pixels, which is pretty close to the SXGA+ standard of 1400x1050.

If Apple uses a 2’ figure for average use distance, then 142ppi will do, or 1101x826. But that’s too close to make any kind of marketable difference, and it’s at the hairy edge of acceptable Retina Display resolution. If anything, they’ll shoot for over, not under.

Anyway, at 1400x1050 pixels, that’s not even twice as many pixels to push, and is a much more reasonable expectation of the iPad 2’s hardware.

Bottom line? Here’s my bet: if—and that’s a big if—if Apple changes the iPad resolution for the iPad 2, I’m going to bet on somewhere between 175ppi and 200ppi, favoring the upper end of that range.

Speaking of bets, John Gruber hasn’t taken me up on my bet. I don’t expect him to—heck, he’s a celebrity! But I think my wager requires clarification: I’m not betting whether or not Apple will change the iPad resolution with the iPad 2, but rather that if they do, it’ll be to something other than (and less than) “x2.” So that’s the wager: if they do, it’s less than two.

In this article, Gruber makes some good arguments against a double-resolution iPad 2 display, chief among them that it’s one helluva’ lot of pixels to push. I have to admit, I’m with him on that.

But I side with Engadget which thinks that the display resolution will increase, i.e., it won’t remain at 1024x768, but won’t double, either. Gruber thinks that’s unlikely, too, because that would require graphics to scale up from original iPad resolution to some new iPad resolution, a non-integer (i.e., “not easy”) multiple. And that would require developers to implement three different graphic designs for their programs in order to make it look pixel perfect.

Here’s where he and I disagree.

First, I think the iPad display looks great, but not that great. I’m comparing it to an iPhone 4 which looks absolutely frickin’ fantastic. Today’s iPad looks positively dowdy in comparison, and I think Apple knows it. A resolution bump is a good fix.

Second, I think that this change might result in a push for developers to use Core Graphics and Quartz 2D to create resolution-independent graphics. (App icons still remain a problem.) In general, I think Apple is gently pushing developers in this direction, so it kinda’ fits.

Third, where bitmap graphics are required (icons, for example), my guess is that we’ll see developers encouraged to create 2x graphics and let the hardware do scaling down, not up. That’s considerably easier to do and have decent results.

Finally, all of Quartz 2D and Core Graphics is implemented as floating point. There’s nothing special about the number “2” except that it is easier for graphic designers to deal with in the land of integral pixels. Each UIView, the iPhone container for any kind of on-screen graphics, goes through a massive amount of floating-point computation (the “transform,” if I understand things correctly) before bits are moved to the screen buffer. Because we’re not dealing with integer math, there really is nothing inherent in the system which makes dealing with one screen size and/or resolution any easier than any other.

So while I am completely on board with the “no double resolution,” I’m willing to bet John a Dogfish Head World Wide Stout (which costs considerably more than my usual nickel bet) that we’ll see a non-integer bump in resolution with the iPad 2. It’s feasible and—I believe—likely.

This article tells you how to download the software for your iOS devices directly in Safari and then tells you that you can tell iTunes which update to install manually.

However, there’s also a great use for these directly-downloaded files if you have multiple iOS devices to update. Use the referenced links to download multiple iOS updates simultaneously—the total for downloading all of your updates is as long it takes for iTunes to download just one update. Then put the files into the appropriate ~/Library/iTunes/(iPod/iPhone/iPad Software Updates) folder.

Then, when you plug in your iOS device for updating, the download process is skipped, the update is verified, and you’ve saved yourself waiting for sequential downloads to occur.

Is this a big deal? Could be. I plug in multiple iOS devices and update as many as I can simultaneously and once you click “Update” for one of them, all operations are halted for the others. (You did know iTunes will do more than one device simultaneously, didn’t you?) Last night, I had to update two iPads, iPhones 3G, 3GS, and 4, and iPod Touch G2. That’s five firmware files and would have been about 1.5 hours of downloading via iTunes vs. 15 minutes with Safari.