I made the assumption that the chips were designed by very smart people with the aid of computers, the construction of each component was done by sophisticated machines, and the human workers along the process were largely limited to final assembly and testing. I was quite wrong.

By now you’ve surely heard of (and hopefully read) the New York Times article Apple’s iPad and the Human Costs for Workers in China. Another good source for information about the topic is Mike Daisey and the Apple Factory. Both of these tell of the horrendous factory conditions in China.

Although Foxconn is the most common manufacturer that we see complaints about, it’s not the only one with problems and Apple isn’t the only company that uses Foxconn (both Motorola and Samsung employ Foxconn for some of their work). Regardless, Foxconn has had the most major, publicized problems, including deadly accidents and worker suicides, and many of those have been tied to Apple’s iOS products in particular. As outraged as I was after learning more about these conditions, I figured Apple’s users would be even more upset, so I browsed some sites looking at forums and comments and was rather disheartened.

AppleInsider published an article called Former executives accuse Apple of ignoring supplier labor abuses that outlined a few of the points from the NYT article. Here are some example responses:

So cowards are willing to make accusations without providing evidence or their manes[sic].
What a joke.

Give us name and dates…. — Patranus

Apparently anonymity means the info is invalid (well, except in the latest iDevice rumors, of course).

….what’s even more pitiful is to blame Apple for a Chinese Corporations[sic] bylaws and worker right conditions–China is responsible for them. — mdriftmeyer

In other words, humanity doesn’t cross borders.

The truth is 99.9999% of those workers are thankful of Apple for their jobs. Their standard of living has increased tremendously since having worked in the rice paddies for a third of the pay. — Dickprinter

I doubt this, but even if it were true, it doesn’t validate the terrible conditions for these workers.

Why? Is Apple guilty of everything they are accused of until we prove them innocent?
Or is it the job the shadowy accusers to bring the proof? — Suddenly Newton

No, they’re not guilty of everything unless there is proof, which has already surfaced and is continuing to be revealed. There’s at least enough evidence to warrant an investigation, and not just of the production lines that develop Apple’s devices. I doubt if Apple is guilty of violating any laws, but laws and morals aren’t always aligned.

To be fair, AppleInsider tends to be extremely pro-Apple and highly focused on the value of Apple as a company (as opposed to Apple’s values). Comments there often focus on stocks and profits as the only measurements of success for a company. So I checked MacRumors article Former Apple Executives Address Working Conditions in Suppliers’ Factories

The sad truth is that we want cheaper products so they use countries with lower wages and worse working/living environments. If we’d all accept a 300% jump in the cost of electronics we could manufacturer everything locally. — AppleDroid

Finally, a reasonable post! The thing is, we don’t need to manufacture electronics locally. Apple has about $100,000,000,000.00 ($100 billion) in the bank, so they can clearly afford to pay manufacturers extra and build in clauses to their contracts with these manufacturers requiring that extra amount is used to improve workers’ conditions.

…news like this sheds light on corporate responsibility being more of a marketing term than a way of doing business. As a company currently sitting with $97.6 BILLION dollars in CASH ON HAND, they should dramatically improve the working conditions and lives of people who make their products, not have an attitude of “well everyone else does it.” While their position is popular on this forum, it’s not right. — theheadguy

Well said!

Looks like the Times is aiming for a Pulitzer. No coincidence that they released the story after Apple announced earnings.

While this is a huge problem, it is not an Apple problem; it’s a worldwide one. The media likes to attach Apple’s name to these stories because Apple stories = eyeballs. — rdowns

I’m sure it isn’t a coincidence. Apple pulling in $13 billion dollars in profit and workers dying, being subject to neurotoxins, etc. makes for a harse contrast. The extra eyeballs can help bring change, and Apple is in the best position of any tech company to make changes.

Americans may not be so inclined to complain about conditions elsewhere when they realize how much more they would have to pay for the crap they buy if everything was like conditions in America. — Undecided

In other words, Americans might care more about money than human lives. Sure, some will, but I think that’s a very tiny portion of people when the real situation is brought to light. We’re talking about the cost of making manufacturing conditions safe instead of working people >60 hours per week in hazardous environments.

All-in-all the Mac Rumors comments were far more informed and intelligent responses than the AppleInsider comments; further, most of the heartless comments were downvoted to some extent. 9to5mac had comments fairly similar to those of Mac Rumors.

Finally, responses from a couple of big Apple fans. The first comes from MG Siegler’s This Is Why We Can’t Have Nice Things post; the second is from John Gruber’s site (he doesn’t appear to make direct links available).

The post focuses on Apple because Apple is now arguably the most successful company on the planet. If they were, say, the 8th largest computer manufacturer, they probably wouldn’t have even been mentioned….

Does that excuse Apple’s behavior in some situations? Not at all. But there also isn’t enough background here to know if Apple is even the worst enabler of these poor working conditions.

…The fact of the matter is that we live in a world that demands amazing technology delivered to us at low costs and at great speed. That world leads to Foxconn. — MG Siegler

I felt like Siegler’s post tries to satisfy both parties, the pro-Apple side and the let’s-do-something-about-it side. His comments boil down to “Well, it sounds bad, but we can’t fully trust NYT and plus there are probably some other companies that are worse. Also, we want cheap electronics.” I disagree that this has to lead to Foxconn, and I also think it’s likely that Apple is among the worst offenders because they have more clout than a smaller company and a few of the quotes indicate as much. Regardless of who is the worst, Apple is making more than enough money to do something without raising the cost of their electronics, so it’s not a matter of “Is Apple the worst” but rather “What can we do about it?”

Tim Cook responded in a company-wide email. — John Gruber

Either Gruber simply doesn’t care about the NYT story or he fully supports Tim Cook’s (Apple’s) position. He tends to be a man of few words when it comes to commenting on many stories, but he will write more than a sentence when it’s important to him (such as like how he thinks the Android buttons are “broken”).

Cook basically said, “We do a lot and anyone who says otherwise is lying.” He points to the Apple supplier responsibility site, which (even if 100% accurate) still shows only 38% of the companies Apple audited meet the working hours requirements established in Apple’s Code of Conduct. In 2011 it was 32%. In 2010 it was 46%. In 2009 it was 41%. Not great numbers.

The simple fact of the matter is that Apple has been pointed out as they’ve got more than enough money to do something about it and many of the major articles related to deaths and injuries at these manufacturing companies have been tied to Apple. Is that fair? Probably not. Does it matter if it’s fair? No. The point is, awareness of the issue needs to be raised in order to make something happen. After all, when enough people compained about the iPhone 4 dropping calls, Apple gave in and offered free bumper cases. If enough people complain about the dangerous conditions at manufacturers, Apple will be willing to do more about the conditions. Hopefully Apple won’t have to lead the way for technology companies to expect more from their suppliers, but it’s better than ignoring the issue.

First and foremost, the iPhone is way too small. The 3.5 inch screen is nice when I’m holding it 8 inches from my eye, but out and about it feels like my hands belong to Andre the Giant. I try to touch the screen and my thumb covers at least 10% of the surface area. How can you have accurate touches like that? I guess I should file down my thumbs and fingers. It’s so tiny that it killed all two-handed operations for me (especially since you can barely fit two thumbs side by side). I’ll admit that for some pockets, having a tiny screen is nice, but 4.3 inches might be better. This is just too small.

While the screen is too small, I’m happy that Apple has stuck to their decision to have one button that does different things depending on what version of the OS you have and how many times you press it and even how slow your presses are. It’s like opening a Christmas present every time I press the home button. Will I go to the home screen? The search screen? The recent apps? The Siri frontend for Wolfram Alpha? The music app?

To be fair, the small screen on the iPhone did introduce me to some new people. I heard that you can do a five-finger swipe to bring up the multitasking bar, but I couldn’t fit five fingers on the screen, so I had to go to Starbucks to find some fellow Apple users with smaller fingers to try. Then I found out that gesture just works on iPad. When will Apple develop a consistent user experience?

I like the missing software back button that is always in one place like on the Galaxy Nexus. On the iPhone, you can have it sometimes be in the top left with the word “Back” or “Home” or something else, or at the top right with the word “Done” or at the bottom as a “Cancel” button. This forces the user to be much more aware of the UI and whether something is a modal dialog, an action sheet, or whatever else. (Of course, the iPhone still has a power/wake button on the top.)

I also like the lack of indicator light on the iPhone. It’s helpful because I can make sure everyone knows I use Apple products since I have to always hold up my phone to turn it on to check for messages and people can see my important Apple logo and know that I’m creative. Why Samsung included a multi-color indicator light that tells me exactly what I missed without turning on the device, I will never understand.

The rest of the iPhone hardware leaves something to be desired. The Galaxy Nexus feels like a completely and thoughtfully designed product. By comparison, the iPhone is made of glass, something we intuitively think of as fragile. It’s also heavy/dense, giving it the consistant feeling of 80s technology that goes well with the click of the home button (or double click or long click or…). It’s not awful, but you’d think Apple could do better at this point. Some people will like not having the option to remove the back to get at the battery because that makes the iPhone almost as thin and as light as the Galaxy Nexus and gives you an excuse to buy a new phone every year.

The battery life itself is very good. I felt like the iPhone was lasting at least as long as the Galaxy Nexus on a fully charged battery, perhaps even a bit longer in some cases. Of course, I don’t have to worry about having the option of using it on 4G and possibly lowering the battery life.

The camera on the iPhone 4S is definitely worse than the Galaxy Nexus in both terms of front-facing camera (the 4S has a measly VGA camera and the Galaxy Nexus has a front-facing camera capable of 720p… a resolution the iPhone can’t even display) and in speed. If you want to get a picture of where something exciting was happening two seconds ago, the iPhone 4S will not let you down. Just press the shutter button when the scene is composed and you’ll get the scene that happens two seconds later. It’s like time travel.

And let’s talk about iOS 5. There is no question that the software is much improved over previous iterations in terms of copying Android’s notification system (though improved with X close buttons that are polished so much that they shrank to a size where you need a 2-year-old’s pinky to press them) and supporting Twitter. You know an OS has improved when Twitter is a selling point.

Unfortunately, the system still lacks much of the features that Android users enjoy. The majority of iOS users will probably think such criticism is bullshit, but that has always been the case. I imagine it’s probably pretty hard for a person who bought the car that made the most sense to him or her to explain to the person who bought a Prius because it was popular how perception affects the driving experience. The person with a personally-fitting car can attempt to explain why he or she likes a stick or more room, but the Prius owner will just believe that having the car pick gears for you is the best and would never spend enough time with any other car to appreciate the differences.

Still, if the iOS team ever wants to convert (or at least convice) most Android users, they still have quite a bit of work to do here. Then again, they probably don’t (or shouldn’t) care too much about converting Android users over to iOS. All the non-smartphone users out there remain the much bigger prize to go after (for both Apple and Google).

Other things that will sound like nits but drove me crazy with iOS 5 included having widgets only in the notification center. If I am adding a widget, I clearly want to see it where I want it. Why should I have to have it sit somewhere invisible that requires an extra swipe? What’s the different between being on my homescreen and having to open a full weather app (iOS4) and being on the home screen and having to swipe down the notifications to see the weather widget (iOS5)?

Another: why do I have to go into the Google Voice app to make a phone call using my Google Voice number? Google baked in support for alternate dialers into their OS; why didn’t Apple? If they’re worried about competition, why did they finally approve the app after a year-and-a-half and an FCC inquiry? Why is Siri letting people look at my private calendar while my phone is locked? And why on Earth is the web browser not the desktop version of Safari yet!?

The new WiFi-syncing is nice — I love not having to find the proprietary cable. But my god Apple needs help with iTunes. I have to reboot my computer into an OS they support and leave it on while my phone is plugged into a power outlet. As if iTunes weren’t already the worst software on the planet, I also have to waste a bunch of electricity keeping my computer on all the time in one of the two OSes Apple supports just to sync my data?

Apple’s universal support of voice dictation is a joke compared to Ice Cream Sandwich.

Some other authors have noted that iOS is ahead of Android when it comes to custom settings for apps, but I have to disagree. Why do I have to leave an app to go find the settings app to change the settings for the app I was just in? That’s completely illogical. Of course, some apps support changing their settings within the app and others don’t, so now we get back to the inconsistancy problem present in the iOS experience.

When it comes to web browsers, arguably the most important feature of any of these devices, there is no question that Android still has a big edge here. I’ve seen arguments on both sides for why iOS does not support third-party plugins–but doing a simple test proves that much of the web is still inaccessible from iOS. Worse, many pages render as large missing tiles featuring a checkerbox to keep the illusion of scrolling smoothly, even beyond the point at which the actual page ends. You try pinching to zoom and everything just stays fuzzy until your fingers stop moving. How am I supposed to know if the text is large and clear enough if it just zooms in and out on fixed pixels?

You’ll also see a bit of impossibility in iOS when you do simple things like trying to attach a file to an existing email draft or trying to attach a second file or trying to store any arbitrary data on your device. For the most part, iOS 5 does a good job of hiding its limitations, but there are plenty of times that you’ll still hit your head on a wall here and there.

The main problem I have with apps on iOS is that, well, they aren’t on iOS. I try to find my favorite keyboard replacement (SwiftKey) and it’s nowhere to be found. I try to get the ever-useful Wifi Analyzer, also not available. I’ve heard that the entire experience has a lot more polish on iOS, especially with the Twitter integration, so I gave it a try. I found one of my favorite links online and decided to open it on the Galaxy Nexus and the iPhone to verify it looked right. For the Galaxy Nexus, I simply clicked the Chrome to Phone button and it instantly popped up on my device. It looked good, so I long-pressed on the URL within the browser, picked share, selected my favorite Twitter app (hint: not the official one), and sent it with a tweet and a comment. I tried that on iOS, which involved trying to type the long URL in by hand in the stock keyboard. That was a pain, so I decided to long-press it in the Android browser again, share, and send it via Google Voice to the iPhone. I opened it in the iPhone, it looked pretty much the same as on the Galaxy Nexus (though tiny), so I copied the URL, pressed the clicky home button (just once), scrolled to the right through ten screens of apps, opened a Twitter app, pasted it into the new tweet box along with a comment, and tweeted.

It’s these tangibles where Android holds the huge advantage. And just like in sports, you can clearly teach the fundamentals. At some point, Apple may simple have to acknowledge that Android works better than iOS because Android’s entire open concept is woven into the product. Apps can properly communicate to each other without having to know of the other apps. The user can do what he or she wants. Even the launcher app can be replaced. Apple’s strengths are elsewhere; they should embrace that.

Apple has done some very nice work here. Both the iPhone 4S and iOS5 are a new pinnacle of the iOS platform. But in the end, it still comes down to something very simple: which device do I want to use day-to-day? Which phone do I reach for when I’m not doing a review? It’s still an Android phone. Without question.

Keep at it, Apple.

(For those who don’t know, this is a parody on the post MG Siegler did called “An iPhone Lover’s Take On The Galaxy Nexus.” I strongly recommend that you buy the phone that makes the most sense to you, whether it’s an Android phone, an iPhone, a Windows phone, or whatever. Any useful review will highlight the strengths and weaknesses of a given device and never tell you that it’s the one-size-fit-all solution.)

At the end of July, I moved on from Treemo Labs. I already had a one-month contract in place for some simple Android developer work, so I was not taking any time off (well, after the extent to which I had been working, dropping to 8 hours a day felt like taking time off). CBS Interactive also contacted me and talked to me about the possibility of a position there. I flew down to Los Angeles to quickly meet everyone and get a more detailed explanation of what they were looking for (and let them know what I was looking for). It was a great trip, and I finally got to put faces to many of the names I had worked with while at Treemo Labs via email and conference calls.

After a bit of negotiation, I accepted a position at CBS Interactive as a mobile developer, and I started to pack up, reserve an apartment, etc. That’s the position I alluded to at the end of the other post. Well, things changed rather suddenly when some contract agreements got in the way (business protection agreement legalese) that removed the posibility of me holding that position. It was an unfortunate and unexpected turn of events that forced me to take a seat and consider my options.

There is no shortage of mobile development positions out there, but I wasn’t interested in making unexciting apps and I started to question whether moving out of the Seattle area would be worth it for me. I was bombarded by recruiter emails offering great clients, unbeatable opportunities, and pleas to contact all my developer friends on the recruiters’ behalf. A few were interesting on the surface, and I pursued them while simultaneously considering the possibility of working for myself full time.

I created wireframes and documentation for a game I decided to develop (and tweeted about it). With my excitement for that app growing, I determined a timeline for the game with a mid-October alpha and calculated out how long I could live without income. Things were looking very positive. Even if I didn’t make much on the game, I had plenty of time to ensure it was done well before having to consider looking for a job. If nothing else, it would teach me a lot and be another bullet on the resume.

Then I was contacted by ARO, a stealth-mode startup in Seattle. I was intrigued, so I interviewed and found out about their goals–definitely some exciting stuff that could push mobile beyond where it is today. I received an offer from them the next day. Considering their goals, offer, and ability to move fast (vital for anywhere I work), I accepted the position.

So, I am a salaried employee at ARO, working on some awesome stuff and, now that I have time outside of work as well, I’ve been taking on some outside projects. I wrote about reviewing Android for Programmers recently. I am also going to be creating an Android video series for developers (details to come) that I’m very excited about. In the near future, the app I’ve been developing for Android Police will be coming out, and then I’ll spend a little more time on the Disease to Dust game (though I don’t expect a beta this year). I’m sure I’ll spend a little time here and there on other projects (such as prepping Predator Clock Widget for improvements), but life is good right now.

As a reviewer, I found it interesting to see other people’s approaches, offering just a bit of guidance here and there to follow common/best practices used my most Android developers. In one chapter in particular, you learn how to create a game called SpotOn that makes use of property animation (from Honeycomb) to create moving targets. This is a great use of property animation that not only demonstrates a core feature in Honeycomb, it also shows how easily you can use the SDK to accomplish what would otherwise take a lot more code.

If you’re considering learning Android app development or know the basics but want to broaden your understanding, definitely take a look at Android for Programmers: An App-Driven Approach. (And I don’t earn any royalties; I just love the “real code” approach that this book takes.)

For a variety of reasons, I finally decided to have Lasik surgery a bit over three months ago.  I had heavily researched it before, but I kept debating with myself before I determined that I should go through with it.  This post is a reflection on the surgery, recovery period, and overall experience.  This post might help you decide to have or not have Lasik surgery. Note that prior to the examination that determines if you’re elligible for Lasik, you should be out of contacts for at least a week (and two weeks before the operation itself).

The first eye checkup I had, my eyes were carefully examined and topographically mapped by the technician.  Then I met with the doctor to review the options and discuss the fact that I have slightly larger-than-average pupils.  There are a variety of corrective eye surgeries to consider and, even after deciding on a specific one, there are options to evaluate.  Lasik essentially revolves around the idea of cutting a flap in the surface tissue of your eye that can be folded back so that a laser can reshape the cornea underneath.  The flap is then positioned back in place, which is what allows the healing process to be relatively fast.  You can choose to have the flap cut by a blade or by a laser (I opted for the precision of a laser) and then you can choose which type of reshaping treatment you have done, traditional or wavefront (which was my choice because it offers more precise and personal eye corrections).  Note that the checkup involved having my eyes dilated, so I recommend you either have some good sunglasses or a driver for the trip home.

The Operation
The day of the operation, I didn’t have to worry about eating anything specific (though they did recommend avoiding alcohol for a few days as it can dry out the eyes).  I simply had to show up and have transportation available, since you cannot drive after the operation.  They did another quick check of my eyes to ensure that the measurements were the same and nothing had come up, and then they gave me some numbing drops in my eyes.

I sat and waited, relaxed but excited.  After fifteen minutes or so, the drops had done their job and I was led into the operating room.  I was told to lie down and get into position, so I did.  They did another quick check of my eyes before beginning.  The first step was to put some kind of clamps in place that would prevent me from blinking.  Once they were in place, I felt like my blinking was restricted but not in a painful or uncomfortable way.  Next, they applied a corneal suction ring.  As it was being applied, by vision dimmed and the laser cut the flap.  They lifted the flap and pulled it back, a strange process to experience.  I didn’t feel anything, but it was somewhat disconcerting to have all focus lost from my eyes.  I thought briefly, “This is what being blind could be like.”  Of course, I could still see a general sense of color but no detail at all.

I was then told that I would need to stay focused on the light for fifteen seconds while my cornea (more specifically, the stroma) was reshaped by the laser.  At that point I thought the light was just some kind of guide light, but it occurred to me later that it was probably the laser itself.  The light was so blurred that it took up much of my vision.  Imagine seeing a light through a foggy window and then blur that even more to have some concept of how unclear vision is at that point.  Once or twice, I had a hint of the smell of burning but never enough to really confirm that I was definitely smelling it and not just imagining it, since that had been one of my worries before the procedure (I really hate when you can smell burning tissue of any kind, even at the dentist’s office).  The other eye took a little longer since vision was slightly worse, but it was the same experience.

The flaps were positioned back over my eyes and double-checked, then they took off the clamps from my eyes, so that I was again free to blink.  They had me get up and sit at another location where I could rest my chin and have the doctor do a full examination of my eyes to verify the flaps were in place and there was no debris or any other issue.  Satisfied everything was okay, I was given a seat in a nice, relaxing room to rest my eyes while waiting for my ride to arrive.  When he did, they helped guide me back to the entryway to meet with him.  At that point, my eyes were definitely much better, but they felt rough and I had sensitivity to light and some difficulty focusing (all normal).  I had a bit of excitement in me after realizing that my vision was already improved.

Post-Op
On the way home, I alternated between resting and trying out my new vision from behind a pair of dark sunglasses.  I kept finding myself mesmerised by the ability to see details, license plates, far away signs.  I was satisfied, but blinking felt rough.  People often describe it as feeling like sand is in your eyes, but it wasn’t as severe for me.  It was more like dry eyes plus a sense of, well, a flap having been cut in my eye.  It wasn’t sharp or stinging, just not smooth.  When I arrived home, I thanked my driver and rested on the couch.  I put drops in my eyes, put on protective eyeware (similar to safety glasses to prevent you from accidentally rubbing your eyes), and fell asleep.

When I awoke a few hours later, I was already feeling much better.  I was told to try to avoid anything that requires focusing (reading, TV, basically everything), but I couldn’t help myself and kept testing my ability to focus clearly and quickly.  I was surprised at how fast my eyes could already focus on anything as I looked around the room.  The one problem that I noticed was lights were extremely hazy and brighter lights had “starbursts” around them, but I had been told that was normal.

I had to use steroid eye drops once every three hours as well as antibiotic eye drops at the same interval (though not at the same time in order to avoid one drop flushing out the other).  Those were for speeding up the healing process and preventing infection respectively.  One of the drops caused a bit of irritation in my right eye; apparently I had a very minor cut in my bottom eyelid (felt like a paper cut), but it wasn’t too bad.  I also had some redness around my eyes from where the suction had been applied.  I regularly used artificial tears (eye drops that are individiually packaged), which helped a lot.

The day after the operation was a Saturday, and I had a relatively early (I think 8am) appointment to get a quick checkup.  I had to have a ride for this trip as well, though I felt like I could have driven just fine.  The checkup was quick and painless, really intended just to catch any potential problems as soon after the surgery as possible, and I had a follow-up appointment scheduled for the next Friday.

Continuing Recovery
I was fine for work that next Monday morning, though I was still taking the eye drops regularly.  At times, I found focusing to be slightly difficult and at other times it was not.  I think my eyes were still getting used to their new ability to actually focus on their own.

I found myself having a tough time falling asleep for a while.  Part of it was because of the annoying safety glasses (which I stopped wearing a bit early) and part of it was because right as I was about to fall asleep I would get the urgent thought “You need to take out your contacts!”  I would bolt awake only to realize I wasn’t wearing contacts.  If you have never worn contacts, you probably do not realize how much it can suck to fall asleep in them.  When you wake, your eyes are completely dry and the contacts are glued in place.  It’s not pleasant, especially if you need to remove them.

It was strange being able to just see.  I could clearly see the smoke detector light at night.  I often woke up and looked out my window to see very sharp and clearly defined leaves from trees, whereas before I could barely tell a window was even there.  I saw details on mountains far in the distance.  My vision was definitely better after surgery than it was with contacts before.

I had my one-week checkup, my one-month checkup, and my three-month checkup with no issues.

Final Thoughts
Vision is amazing, particularly good vision.  Prior to surgery, I couldn’t read the giant “E” on the eye charts; hell, I couldn’t even tell there was anything on the chart.  Now I am seeing better than 20/20.  The surgery cost me about $3400 out of pocket, plus probably $50-$75 more for the eye drops, so it definitely wasn’t cheap (don’t expect much help from insurance, since it’s an “elective” procedure).

For some time after the surgery, you have to avoid certain activities such as rubbing your eyes or swimming, but I think the inconvenience was minimal given the amazing benefit of having naturally good vision.  I can wake up in the middle of the night and just see things.  It sounds far from amazing if you have never had terrible vision, I know, but I definitely consider this to be one of the best things I’ve ever done with my money.

The only problem I have had from the surgery is that I still see starbursts, mostly on bright lights at night.  The doctor said I would probably experience this more than average because my pupils are a bit larger than average (I think 8mm vs. the average 5-7mm).  The starbursts have slowly gone down some and I have gotten a bit more used to the problem, but it is more prevalent than before the surgery.

That said, I would absolutely make the decision to have Lasik again without hesitation.

There are three types of patents (this applies to the United States; my knowledge of patent laws in other countries is minimal): utility, design, and plants. Utility patents cover what you’d typically think of as an invention, everything from Velcro to turbines. Design patents cover “a new, original, and ornamental design for an article of manufacture,” essentially, the appearance of a manufactured product. Finally, plant patents actually cover plants… invent a new and distinct plant that can reproduce on its own and you can patent it.

Unfortunately, applying patents to software is a difficult practice and has significant repercussions. This is the very reason that there is no standardized way to play video on the web. Proponents largely fall into two camps: ones that support the well-known, highly efficient H.264 codec and ones those who support an open, freely-available codec such as VP8. The H.264 codec is heavily patented and can prove to cost millions for a non-profit company like Mozilla; however, the patents are known and so the expense is clear. Codecs such as VP8 and Theora are freely available, so they are excellent options for companies that have limited funds and/or choose to promote open software; the alternate argument is that these codecs are less efficient because they had to be specifically written to not do things similarly to H.264 but they still might infringe on a patent. When you consider that H.264 is covered by 70 pages worth of patents (70 pages listing the patent numbers and corresponding owners, not counting the actual patents themselves), it’s not hard to imagine that other codecs could infringe somewhere without knowing it. The very process of patenting that’s supposed to help innovation is scaring people away from using (and even creating) inventions.

Apple has filed multiple suits against Samsung for their phones and tablets. Now, an injunction is in place that prevents Samsung from offering the Galaxy Tab 10.1 in Australia and in Europe (well, they can’t sell their tablets in Germany and have to seek a new import strategy for the rest of Europe) while the lawsuits continue. I don’t see how anyone could use a Galaxy Tab and then an iPad and consider the user experience to be the same, so how valid can the patents be? And as far as design patents go, that graphic I have included shows a digital picture frame that Samsung made in 2006, then the iPad (from 2010), and then the new Galaxy Tab 10.1 (2011). The user experiences are different, Samsung came up with the design first (and didn’t sue Apple), so let both the products go to market and create a benefit for all consumers.

I was going to write a lot more on this subject, but I think the message is clear: software patents don’t work. They stifle innovation and harm the consumer. The only people who truly like software patents seem to be major corporations that can use them to kill competition and lawyers. The system needs to be fixed.

The previous tutorial ended with a simple app built that could display a green screen with RenderScript. The next step to making RenderScript more useful is understanding how to interact with it when it’s already running. We want to be able to pass values to the RenderScript code and we also want to pick up on user interactions with the view.

Since we already know how to set a background color within the init method in the RenderScript file, lets build on that by learning how to set it from the Java side. Here’s where our RenderScript101RS class comes in handy. Just add this method:

	public void setBackgroundColor(Float4 color) {
		mScript.set_bgColor(color);
	}

This simple method takes a Float4 and passes it directly to the set_bgColor method. That method is automatically generated in the glue class and lets you set the bgColor value in RenderScript101.rs from Java.

In the RenderScript101View, we need to override onTouchEvent:

    @Override
    public boolean onTouchEvent(MotionEvent event) {
        super.onTouchEvent(event);

        if (mRenderScript == null) {
        	return true;
        }

        if (event.getAction() == MotionEvent.ACTION_DOWN) {
        	final Random random = new Random();
        	final Float4 newColor = new Float4(random.nextFloat(), random.nextFloat(), random.nextFloat(), 1.0f);
        	mRenderScript.setBackgroundColor(newColor);
        }

        return true;
    }

If the RenderScript101RS reference is not yet set, don’t do anything. If it is set, check to see if we’re getting an ACTION_DOWN event (e.g., touching the screen). If we are, then we create a new Float4 using three random float values and one hard-coded to 1.0f (the transparency/opacity to make sure it is fully opaque). Then, we just trigger our newly created setBackgroundColor method with the generated Float4.

If you run the app now, you can tap the RenderScript view to watch it change colors.

Well, that wasn’t too bad, was it? The next part is going to be a bit more challenging, so we will have a crash course on computer graphics terminology.

The Difficult Part

Three-dimensional graphics revolve around vertices (vertex is the singular form). These are essentially points in space that can be used to construct more complicated graphics. Moving the vertices around is called “transformation.” The mathematical construct that accomplishes this is called a “transformation matrix.” There have been many, many books written on these concepts, so it’s impossible to condense everything down into a blog post; however, here are some specific terms for understanding RenderScript for Android:

• ProgramStore – This controls how the framebuffer is used. For instance, you can enable or disable depth testing which controls what happens when one pixel is closer to the camera than another (e.g., whether it should blend or just overwrite).
• Sampler – Samplers are used by ProgramFragments to determine how to get the pixels of a texture
• ProgramFragment – The Android-equivalent of a fragment shader
• ProgramVertex – The Android-equivalent of a vertex shader

If you want to learn more about computer graphics, I recommend learning about OpenGL. It’s extremely valuable to learn and many of the concepts from OpenGL apply to RenderScript.

Here is the updated RenderScript101.rs file:

#pragma version(1)
#pragma rs java_package_name(com.iangclifton.tutorials.renderscript);

#include "rs_graphics.rsh"

float4 gBgColor; // Background color as xyzw 4-part float
rs_allocation gBgImage; // Background image
rs_sampler gLinearClamp; // Sampler used by the program fragment
rs_program_fragment gSingleTextureFragmentProgram; // fragment shader
rs_program_store gProgramStoreBlendNone; // blend none, depth none program store
rs_program_vertex gProgramVertex; // Default vertex shader

static const float3 gBgVertices[4] = {
        { -1.0, -1.0, -1.0 },
        { 1.0, -1.0, -1.0 },
        { 1.0, 1.0, -1.0 },
        {-1.0, 1.0, -1.0 }
};

static void drawBackground() {
	if (gBgImage.p != 0) {
		rs_matrix4x4 projection, model;
		rsMatrixLoadOrtho(&projection, -1.0f, 1.0f, -1.0f, 1.0f, 0.0f, 1.0f);
		rsgProgramVertexLoadProjectionMatrix(&projection);

		rsMatrixLoadIdentity(&model);
		rsgProgramVertexLoadModelMatrix(&model);

		rsgBindTexture(gSingleTextureFragmentProgram, 0, gBgImage);

	    rsgDrawQuad(
			gBgVertices[0].x, gBgVertices[0].y, gBgVertices[0].z,
			gBgVertices[1].x, gBgVertices[1].y, gBgVertices[0].z,
			gBgVertices[2].x, gBgVertices[2].y, gBgVertices[0].z,
			gBgVertices[3].x, gBgVertices[3].y, gBgVertices[0].z
		);
	} else {
		rsgClearColor(gBgColor.x, gBgColor.y, gBgColor.z, gBgColor.w);
	}
}

void init() {
	gBgColor = (float4) { 0.0f, 1.0f, 0.0f, 1.0f };
	rsDebug("Called init", rsUptimeMillis());
}

int root() {
	rsgBindProgramVertex(gProgramVertex);
	rsgBindProgramFragment(gSingleTextureFragmentProgram);
	rsgBindProgramStore(gProgramStoreBlendNone);

	drawBackground();
	return 16;
}

Note that I’ve updated all of the global variables to start with “g” in order to keep things a bit more clear. The root() method has been updated to bind the ProgramVertex, ProgramFragment, and ProgramStore right away. Looking at the drawBackground() method, you can see that the old code falls under the else statement. Everything else happens when gBgImage.p is not equal to zero (in other words, the gBgImage has been set).

We create a four-by-four projection matrix and model matrix. The projection matrix is passed by reference and is turned into an orthographic matrix with rsMatrixLoadOrtho. An orthographic matrix is essentially a flat representation of points in space (e.g., the HUD in a first-person shooter). Most commonly, the points are -1 to +1 in each dimension (though we use 0-1 for one here). In graphics hardware, it is common to represent everything with floats because they give more precision than an arbitrary system (e.g., think of how colors are commonly represented by 0-255; in OpenGL and other languages, they are represented by floats because hardware can create an unknown number of unique colors in the future). Then the matrix is passed to rsgProgramVertexLoadProjectionMatrix so that the 3D points can be flattened to 2D points.

We pass model by reference to rsMatrixLoadIdentity which makes model an identity matrix. An identity matrix is essentially a matrix that does not affect other matrices in multiplication (think of it like a 1 where 1 times X results in X). With this identity matrix, we call rsgProgramVertexLoadModelMatrix to avoid manipulating the vertices.

Next, we call rsgBindTexture, which takes a program fragment, an unsigned int (slot), and an rs_allocation. This is essentially where we are setting up our texture (Bitmap) to be drawn. Now that the texture has been set up, we can draw the quad on which it will appear. The gBgVertices are defined on lines 13-18 but we’re essentially passing the top left, top right, bottom left, and bottom right points of the screen. The Z position for all of them is -1, which we set as the maximum Z-depth in our rsMatrixLoadOrtho call. Therefore, this texture spans the whole view but appears at the very “back” of it.

Now we have to update RenderScript101RS to set these new values:

package com.iangclifton.tutorials.renderscript;

import android.content.res.Resources;
import android.graphics.Bitmap;
import android.renderscript.Allocation;
import android.renderscript.Float4;
import android.renderscript.Matrix4f;
import android.renderscript.ProgramFragment;
import android.renderscript.ProgramFragmentFixedFunction;
import android.renderscript.ProgramStore;
import android.renderscript.ProgramVertex;
import android.renderscript.ProgramVertexFixedFunction;
import android.renderscript.RenderScriptGL;
import android.renderscript.Sampler;

public class RenderScript101RS {

	private Sampler mLinearClamp;
    private ProgramStore mProgramStoreBlendNone;
    private ProgramVertex mProgramVertex;
	private RenderScriptGL mRS;
	private ScriptC_RenderScript101 mScript;
    private ProgramFragment mSingleTextureFragmentProgram;

	public RenderScript101RS(RenderScriptGL rs, Resources res, int resId) {
		mRS = rs;
		mScript = new ScriptC_RenderScript101(rs, res, resId);

		initProgramStore();
		initSampler();
		initProgramFragment();
		initProgramVertex();
		mRS.bindRootScript(mScript);

	}

	public void setBackgroundBitmap(Bitmap bitmap) {
		if (bitmap == null) {
			return;
		}
		final Allocation bitmapAllocation = Allocation.createFromBitmap(mRS, bitmap, Allocation.MipmapControl.MIPMAP_NONE, Allocation.USAGE_GRAPHICS_TEXTURE);
		mScript.set_gBgImage(bitmapAllocation);
	}

	public void setBackgroundColor(Float4 color) {
		mScript.set_gBgColor(color);
	}

	private void initProgramFragment() {
        final ProgramFragmentFixedFunction.Builder pfBuilder = new ProgramFragmentFixedFunction.Builder(mRS);
        pfBuilder.setTexture(ProgramFragmentFixedFunction.Builder.EnvMode.REPLACE, ProgramFragmentFixedFunction.Builder.Format.RGBA, 0);
        mSingleTextureFragmentProgram = pfBuilder.create();
        mScript.set_gSingleTextureFragmentProgram(mSingleTextureFragmentProgram);
	}

    private void initProgramStore() {
        mProgramStoreBlendNone = ProgramStore.BLEND_NONE_DEPTH_NONE(mRS);
        mScript.set_gProgramStoreBlendNone(mProgramStoreBlendNone);
    }

	private void initProgramVertex() {
        ProgramVertexFixedFunction.Builder pvb = new ProgramVertexFixedFunction.Builder(mRS);
        mProgramVertex = pvb.create();
        ProgramVertexFixedFunction.Constants pva = new ProgramVertexFixedFunction.Constants(mRS);
        ((ProgramVertexFixedFunction)mProgramVertex).bindConstants(pva);
        Matrix4f proj = new Matrix4f();
        proj.loadProjectionNormalized(1, 1);
        pva.setProjection(proj);
        mScript.set_gProgramVertex(mProgramVertex);
	}

	private void initSampler() {
		mLinearClamp = Sampler.CLAMP_LINEAR(mRS);
		mScript.set_gLinearClamp(mLinearClamp);
	}
}

Looking at the constructor, we can see that first the ProgramStore is initialized, then the Sampler, then the ProgramFragment, and finally the ProgramVertex. Each of these has an init___ method that you can look at. The initProgramStore just sets a ProgramStore that does no blending and no depth testing since they are not needed for the background. Then initSampler just creates a CLAMP_LINEAR Sampler. The initProgramFragment method creates a simple fragment shader. Lastly, the initProgramVertex method creates a simple ProgramVertexFixedFunction (vertex shader) without any custom GLSL.

If you’ve never done any OpenGL or other 3D computer graphics, you’re probably lost by now. Sorry! It would take a few hundred pages to truly clarify all of this, but hopefully some of it is making sense.

Finally, we just updated the RenderScript101View class’s onTouchEvent method:

    @Override
    public boolean onTouchEvent(MotionEvent event) {
        super.onTouchEvent(event);

        if (mRenderScript == null) {
        	return true;
        }

        if (event.getAction() == MotionEvent.ACTION_DOWN) {
        	mRenderScript.setBackgroundBitmap(BitmapFactory.decodeResource(getResources(), R.drawable.icon));
        }

        return true;
    }

We simply update this method so that tapping the view will set the background Bitmap to the default icon. Yup, it looks terrible, but you’ve now experimented with the key features of RenderScript and you might even understand a thing or two.

Note: The source code for this tutorial is available in on GitHub.

We’ll be creating four files:

• RenderScript101.rs – The actual RenderScript code
• RenderScript101RS.java – A helper class to simplify interaction with RenderScript
• RenderScript101View.java – An RSSurfaceView that handles setting up the view and can capture touch events
• RenderScript101Activity.java – Main Activity and it’s even simpler than a typical one

When you create a new project, select a target of at least 11 and let Eclipse generate the Activity for you (ignore it for now). We’re diving right into the actual RenderScript code, so create the RenderScript101.rs text file (in the same folder/package as the Activity). The first things we have to do are to specify the version of RenderScript we’re using (1) and specify the package (I’m using com.iangclifton.tutorials.renderscript).

#pragma version(1)
#pragma rs java_package_name(com.iangclifton.tutorials.renderscript);

#include "rs_graphics.rsh"

float4 bgColor; // Background color as xyzw 4-part float

static void drawBackground() {
	rsgClearColor(bgColor.x, bgColor.y, bgColor.z, bgColor.w);
}

void init() {
	bgColor = (float4) { 0.0f, 1.0f, 0.0f, 1.0f };
	rsDebug("Called init", rsUptimeMillis());
}

int root() {
	drawBackground();
	return 16;
}

When your RenderScript code is first initialized, the init() method will run once. Then the root() method will run repeatedly. The return value for the root method is an int specifying the number of milliseconds before root() should run again.

Looking first at init(), you can see we are setting the bgColor (a 4-part float defined on line 6) to 0, 1, 0, 1. This is in RGBA format, so we’re saying no red, maximum green, no blue, and full opacity. In the next line we call rsDebug with the message “Called init” and the current uptime in milliseconds. Think of this as an easy way to call Log.d("RenderScript", your_message_here). This call is not necessary, but you should definitely get used to adding debug messages into your RenderScript early on. For reference, rsDebug is defined in rs_core.rsh and rsUptimeMillis is defined in rs_time.rsh (both are available in your sdk directory under platforms/android-11/renderscript/include and are included automatically for you).

Jumping down to the root method, we see that it calls drawBackground() and returns 16 (16ms for a frame is close to 60 frames per second). The drawBackground() call only does one thing right now; it clears the screen using the bgColor we set in init(). The rsgClearColor method takes four floats (R, G, B, A) and is defined in rs_graphics.rsh. Remember that RenderScript can also be used for calculations, so you have to specifically include the graphics header file (line 4). If you’re new to computer graphics, the use of the x, y, z, and w properties of bgColor might seem strange. Without getting into the details, this is a convention in graphics where a four-part float is represented with these four letters (as you can probably guess, x, y, and z are typically coordinates. The w is usually for projection where the values are actually represented as x/w, y/w, and z/w. There’s a lot more to it than that, but the important part is knowing the letters right now).

Alright, so all that code does is define a background color from four floats (x, y, z, and w) and then it clears the screen to that color every 16-ish milliseconds. Pretty simple, but it’s a good start.

Next, you want to create the RenderScript101RS.java file to simplify interaction with the RenderScript. It should look like this:

package com.iangclifton.tutorials.renderscript;

import android.content.res.Resources;
import android.renderscript.RenderScriptGL;

public class RenderScript101RS {
    private RenderScriptGL mRS;
    private ScriptC_RenderScript101 mScript;

    public RenderScript101RS(RenderScriptGL rs, Resources res, int resId) {
    	mRS = rs;
    	mScript = new ScriptC_RenderScript101(rs, res, resId);
    	mRS.bindRootScript(mScript);
    }
}

All we are doing for now is setting a reference to the RenderScriptGL (the graphics derivative of RenderScript), instantiating the “glue” class ScriptC_RenderScript101, and binding the script. The glue class is generated for you by Eclipse. If you have automatic builds on and saved the .rs file we just worked on, you might have noticed the class being added to the gen folder along with your R class. This glue class lets you interact with your RenderScript code via Java (such as if you want to set the background color from Java instead of within the RenderScript). We’ll get to it later. The bindRootScript() method simply tells Android which script should handle rendering to the surface.

Next up, RenderScript101View.java:

package com.iangclifton.tutorials.renderscript;

import android.content.Context;
import android.renderscript.RSSurfaceView;
import android.renderscript.RenderScriptGL;

public class RenderScript101View extends RSSurfaceView {
	private Context mContext;
	private RenderScript101RS mRenderScript;
	private RenderScriptGL mRS;

	public RenderScript101View(Context context) {
	    super(context);
	    mContext = context;
	    ensureRenderScript();
    }

	private void ensureRenderScript() {
		if (mRS == null) {
			final RenderScriptGL.SurfaceConfig sc = new RenderScriptGL.SurfaceConfig();
			mRS = createRenderScriptGL(sc);
		}
		if (mRenderScript == null) {
			mRenderScript = new RenderScript101RS(mRS, mContext.getResources(), R.raw.renderscript101);
		}
	}
}

This is the RSSurfaceView that essentially works like other views in Android. In fact, it extends SurfaceView, so if you’ve used SurfaceView or GLSurfaceView, you have a pretty good idea of what this is.

All we’re doing here is following the convention of having an ensureRenderScript() method that sets up the RenderScriptGL and RenderScript101RS class instances. This method can be called when the view is first set up or when it changes. If mRS is null, we create a SurfaceConfig (this can be used to control the bit-depth for colors, the depth buffer, etc., but we’re just using the defaults). We use the SurfaceConfig in our call to createRenderScriptGL() to generate the RenderScriptGL. If the mRenderScript reference is null, we simply construct a new one by passing the RenderScriptGL, a reference to the Resources, and the resource identifier for our RenderScript file (this bytecode file is automatically generated for you in res/raw).

And, finally, RenderScript101Activity.java:

package com.iangclifton.tutorials.renderscript;

import android.app.Activity;
import android.os.Bundle;

public class RenderScript101Activity extends Activity {

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(new RenderScript101View(this));
    }
}

Yeah, that’s all there is to this Activity. We’re simply constructing a new RenderScript101View and using it as the layout. Run the app on your Honeycomb device and you should see a horrendous green screen like this:

If your eyes are burning, you did it right. If you don’t see a green screen, check DDMS for anything suspicious in the logs.

That concludes part one of the RenderScript 101 tutorial. Next up, RenderScript 101, Part 2: RenderScript Interaction.

I ended up at Treemo Labs by way of a buddy I had worked with at Western Washington University where we were web developers. I had finished my teaching internship, but the economy was weak and teaching jobs (particularly for someone with such limited experience) were not easy to come by. Fortunately, I started up at Treemo doing web development and ended up leaning toward my current passion, mobile development.

I truly enjoy learning and tackling new challenges as well as working with technology and sharing that knowledge and experience with others.  One of the great things about mobile development is the unbelievable pace of change.  It wasn’t long ago that I could name all relevant Android devices and their specs, now it’s simply impossible to keep up.  Now I focus more on the software side of things, playing with all the newest OS features both announced and slipped in.

When I started at Treemo, the G1 and iPhone 3G were the primary devices.  The G1 could do far more than the iPhone and even had some features current iPhones still don’t have, but the iPhone’s narrower list of capabilities was generally executed much more smoothly.  The contrast was intriguing to me–and still is.  In 2009, we saw the Palm Pre come and go, the 3G update to the 3GS, and the G1′s angular cousin, the Motorola Droid, take off.  I had the opportunity to work with all of these devices and many more while at Treemo.  I also got to see the evolution of my skills alongside these changing devices.  I worked on the CBS News app for both Android and iOS as my intro into mobile development, not a bad start!  I developed a variety of Android apps (CNET News, Survivor, Rick Steves’ Audio Europe, etc.), learning from each experience.  Even the last app I developed at Treemo Labs was an opportunity to learn and grow; developing Big Brother gave me the chance to learn more about Honeycomb (and RenderScript in particular) than I would have thought possible, given the time constraints.

As much as I enjoyed working with the people at Treemo, it came time for me to move on. I won’t go into the details, but a lot of signs pointed to the need for a change. Fortunately, Android developers are in high demand, and an excellent opportunity has already come my way. I’ll have a separate post about that later on.

I wrote a review called [Review] ASUS Eee Pad Transformer – A Month With A Tablet In Disguise at Android Police, so I will not go into excessive detail here. If you are looking for a tablet that can actually be used to create real content, particularly for typing on the go, take a look at the Asus Eee Pad Transformer.