Code: http://developer.android.com/shareables/devbytes/ListViewAnimations.zip
YouTube: https://www.youtube.com/watch?v=8MIfSxgsHIs
Friday, February 22, 2013
DevBytes: ListView Animations
How animating ListView items can lead to problems as views are recycled, and how to perform these types of animations correctly with new API added in Jellybean.
Code: http://developer.android.com/shareables/devbytes/ListViewAnimations.zip
YouTube: https://www.youtube.com/watch?v=8MIfSxgsHIs
Code: http://developer.android.com/shareables/devbytes/ListViewAnimations.zip
YouTube: https://www.youtube.com/watch?v=8MIfSxgsHIs
Sunday, February 17, 2013
Engineers Do It Forever
I read an interesting article on The Verge today (Photoshop is a city for everyone), which detailed a short history of Photoshop, to explain why it is the way it is, and how it will continue to be that way.
I enjoyed the article, but one quote in there bugged me:
What irks me is this: Just because an engineer has some level of success, or got the chance to work on a successful product in some previous generation, doesn’t have any bearing on whether they want to let someone else do it. In fact, I’d argue the opposite: any engineer that has worked on ground-breaking, cool stuff will continue to want to do so. You don’t reach a point in your career and think, “Okay, that’s enough.” Or at least, I don’t think you do if you honestly give a crap about what you’re working on, which is the case with most of the people with whom I’ve had the honor to work.
The fact that you’ve done great stuff in the past means you want to do it again. And again. And again.
Sure, there’s probably a time in life where you just get really, really tired. Or dead. But until that time, how the Hell could you live and work in a place and an industry like this and not continue trying to do amazing new things? Case in point: the article’s author interviewed someone that worked on the original version of Photoshop, and then more recently invented Lightroom during a summer vacation. That doesn’t sound like someone that was ready to let that next generation take over. Or maybe he just didn't have any kids to hand it over to?
Maybe this is just me mis-reading the author’s intention here, but it seemed worth clarifying this for posterity, or at least for myself:
Engineers do what we do because we love doing it, not because it pays the bills. So excuse us while we continue doing it until they pry our cold, dead fingers off our keyboards.
I enjoyed the article, but one quote in there bugged me:
"Many of the Adobe employees I met — all fantastic conversationalists — seem like the sort of people whose children grow up to become employees of Google. You know, smart people who’ve had their own heyday, and are now ready for the next generation to shine.”The quote felt more personal to me because I’ve worked at Adobe (albeit not on Photoshop), as well as other venerable tech companies in Silicon Valley, and now find myself at Google.
What irks me is this: Just because an engineer has some level of success, or got the chance to work on a successful product in some previous generation, doesn’t have any bearing on whether they want to let someone else do it. In fact, I’d argue the opposite: any engineer that has worked on ground-breaking, cool stuff will continue to want to do so. You don’t reach a point in your career and think, “Okay, that’s enough.” Or at least, I don’t think you do if you honestly give a crap about what you’re working on, which is the case with most of the people with whom I’ve had the honor to work.
The fact that you’ve done great stuff in the past means you want to do it again. And again. And again.
Sure, there’s probably a time in life where you just get really, really tired. Or dead. But until that time, how the Hell could you live and work in a place and an industry like this and not continue trying to do amazing new things? Case in point: the article’s author interviewed someone that worked on the original version of Photoshop, and then more recently invented Lightroom during a summer vacation. That doesn’t sound like someone that was ready to let that next generation take over. Or maybe he just didn't have any kids to hand it over to?
Maybe this is just me mis-reading the author’s intention here, but it seemed worth clarifying this for posterity, or at least for myself:
Engineers do what we do because we love doing it, not because it pays the bills. So excuse us while we continue doing it until they pry our cold, dead fingers off our keyboards.
Friday, February 15, 2013
DevBytes: KeyFrame Animations
How to use AnimationDrawable to construct a keyframe animation where each frame is shown for a specified duration.
YouTube: http://www.youtube.com/watch?v=V3ksidLf7vA
Code: http://developer.android.com/shareables/devbytes/KeyframeAnimation.zip
YouTube: http://www.youtube.com/watch?v=V3ksidLf7vA
Code: http://developer.android.com/shareables/devbytes/KeyframeAnimation.zip
Wednesday, February 13, 2013
Dealing with Data: A Hard Drivin' Tale of Woe
My hard drive crashed last week, taking all of my data and digital life with it. I've written and rhymed about this already, but I thought I'd jot down some notes about how it happened and how I got my life back in case it helps anyone else in the same boat.
Background:
I have an iMac at home, running Snow Leopard, purchased about 3 years ago. It's been reasonably solid; we haven't had any hardware issues with it until this doozy.
Part I: The Symptoms
My wife complained that the computer had gotten painfully slow, so I took a look at it. Indeed, it was horrible, taking tens of seconds to perform simple tasks and minutes to do something really complicated like launch an application.
I ran Activity Monitor to see what was causing the problem and ... nothing. The CPU was nearly idle, memory usage was well below the physical limits, and the disk didn't seem to be thrashing.
On a hunch, I thought I'd check the disk, so I ran Disk Utility.
(Note to self: This would have been a good time to back up the data on the disk.)
Part II: The Botched Repair Job
"Verify Disk" in the Disk Utility app told me that the disk was not healthy and that I should repair it. It wouldn't let me do this on the boot disk, and told me to boot from the OS installation disk and try it again.
(Note to self: This was another great opportunity for me to back up the disk.)
Eventually (after I asked my wife) I was able to locate the install disk and booted from it (shut the computer down, power it on, hold down "c" after you hear the chime). I ran Disk Utility again, only this time the "Repair Disk" button was not dimmed out, so I clicked it, hoping that it would magically fix whatever had happened.
Repair Disk ran for a minute and then stopped and said that it was unable to repair the disk. It suggested that I back up the disk, format it, and re-install the OS.
(Note to self: This was a good time to regret having not backed up the data already.)
I could not get to the disk at this point, so I rebooted the machine normally (not from the install disk). This caused the machine to boot into the grey booting screen... and then shut off. I tried this a couple of times, and then booted with the install disk again. Once more, I was able to get into the OS, but I was not able to get to the disk (either through the UI or through the shell in a Terminal window). Moreover, the "Repair Disk" button (which had worked so beautifully the first time around) was now dimmed out again. In fact, the drive itself was dimmed out, like the system could see that there was something there, but couldn't actually mount it.
I tried running a Terminal window and getting to the disk, but it was not mounted (nothing in /Volumes), so I couldn't get there and couldn't copy the data.
(Note to self: This was when I realized that I really needed to have backed up everything several steps before.)
Part III: Go to Apple
I took the machine into the Apple Store, hoping that they'd have some advice for me.
The main thing they said was that they don't deal with personal data; as soon as the guy realized that there was data loss involved, he said there was nothing he could do. He gave me the card of a company two hours away and said that they might be able to retrieve the data for me for anywhere from a few hundred to several thousand dollars.
I love my family. And I love the digital pictures of my family that I'd apparently just lost. But I don't love them that much.
He said there was one other thing I could try, although it could risk further corruption that would make retrieval more difficult. But in case I wanted another option: boot the machine as a "target disk."
Part IV: Recovery
Booting as target disk means that you're running the computer as just an incredibly expensive external drive for some other computer. You power it on while holding the "t" key. Meanwhile, you've connected another computer to this machine via a cable that you almost certainly don't have, and the machine looks like just another disk drive to that other computer.
Details:
At this point, my bluetooth keyboard flaked out, in a combination of dying batteries and possibly confusion over bluetooth connection to a machine that didn't have a brain anymore. Fortunately, even a PC USB keyboard has a "t" key, so I was able to use that keyboard to boot into target mode.
I didn't have the cable I needed for this experiment (FireWire). Moreover, none of my other computers even have a FireWire port (newer Macs have Thunderbolt ports instead. I have a theory that they invent new interface standards every couple of years to keep cable companies in business). I ended up ordering a FireWire to Thunderbolt converter and a FireWire cable, which plugged together to connect a MacBook Pro to the dead iMac.
And ... voilà! This actually worked. I plugged it all together, booted the dead machine as a target disk, and was able to see that disk on my other computer. I quickly (okay, it took hours for this much data to travel over FireWire) copied everything I could see on that drive over to my other system and to every other disk I could lay my hands on. I hired monks to transcribe it. I transmitted the bits as smoke signals. I tattooed the binary on my body. I had my children memorize long strings of hex.
Data recovered.
The weird thing here, to me (arguably not the most knowledgeable of people about disk drive technology) is that the disk was clearly screwed up enough that it would not mount when the machine was booted with the install disk, but it was good enough to be visible across FireWire.
Whatever. I had my data back.
(Note to self: At this point, I felt like I'd cheated the system, since by rights I should not have been allowed to get my data back. But I'm okay with this. Crime may not pay, but cheating's not exactly a crime.)
Part V: Replacement
I searched for information on replacing the internal drive on an iMac and discovered that my machine/drive was actually under recall because apparently these particular Seagate drives are known to fail. So on the positive side, at least the replacement was easy and free. It's something I'd rather have known before the drive failed (apparently they do notify customers of these recalls; I may have missed that crucial memo). But at least I got the new hardware I needed, along with a clean install of my original OS.
Part VI: Back Up Your Damn Data
Now I have a working machine/drive again, and I have all (I hope) of my data on other drives. I am now ready to copy everything back and start using the machine again. But first, I'm going to figure out a backup plan. Because I know me, and if I just start using assuming I'm going to get to it soon, I'll be writing another piece in a couple of years about how I lost everything. Again.
I've polled several friends about what they do and the options boil down to these:
- Local backup
- Cloud backup
- Local + Cloud backup (for the truly paranoid, in which crowd I might now count myself)
Local backup:
There are a few options here, including:
- USB drive connected to a computer you want to back up, or a network drive connected to the network that the system is on (or at least can reach). Copy stuff manually (probably not a good idea, unless you're way better at doing this than I am), or set up some kind of automated backup solution, including the Mac's Time Machine. Note that you probably want to ensure that the backups actually happen; I had actually set up Time Machine in the past for the machine that died, but the drive decided to go to sleep and never wake up. So that didn't help.
- RAID array: This is an option on some desktop systems, where you can have disks that are essentially copies of each other, so if one goes out, the data is still alive on the other one. Swap out the bad disk for a good one and you're back in parallelizing business. This is not an obvious solution for an iMac since it only has the one internal drive.
Cloud backup:
The options that I've heard about most frequently included:
- DropBox and Google Drive: I've used the free version of these applications for a while, as a convenient way to exchange large files between computers. Recently, I've also started to use DropBox as a synchronization mechanism for some software that I use. And I use Google Drive for my various Google Docs. They both offer a small amount of storage for free (2GB on DropBox, 5GB on Google Drive). If you pay, they'll provide more storage (DropBox currently offers 100GB for about $10/month, Google Drive is about $5/month for the same 100GB).
The way these services work as a backup solution is that applications create a folder on your computer that is linked to their cloud service. You then create/copy/move anything you want backed up into that folder and it automatically syncs to the servers of these apps in the cloud. Essentially, you start using that cloud folder for all of you documents that you want to back up, and the service takes care of uploading it for you automatically.
- CrashPlan: This application is a bit more flexible; it allows you to specify various parts of your system that you want backed up and it automatically copies those items to its servers and keeps them sync'd over time. Also, it apparently encrypts the data that it uploads, so that you can feel a bit easier about your secure files that you're tossing up into the cloud. The prices vary, depending on how much storage you want, how many computers you want to back up, and how long a term you want to pre-pay.
- Carbonite: Like CrashPlan, Carbonite backs up everything you choose on a single system, encrypts it, and sends it off to the company's servers. You pay an annual fee ($59), or less per year for longer terms.
Local + Cloud
Some people are doing a combination of the above, where they have multiple local copies, but they also keep some of their core data backed up using one of the cloud services above.
I'm sure I haven't covered the full spectrum of backup possibilities here, but these are the main ones that have come up in my recent discussions with colleagues, friends, family pets... anyone that would listen to my tale of woe and help me figure out how to not fall into this pit of data Hell again.
Part VII: Conclusion
See Part VI: Back up your damn data.
Watch my video on the subject if you need more motivation.
Background:
I have an iMac at home, running Snow Leopard, purchased about 3 years ago. It's been reasonably solid; we haven't had any hardware issues with it until this doozy.
Part I: The Symptoms
My wife complained that the computer had gotten painfully slow, so I took a look at it. Indeed, it was horrible, taking tens of seconds to perform simple tasks and minutes to do something really complicated like launch an application.
I ran Activity Monitor to see what was causing the problem and ... nothing. The CPU was nearly idle, memory usage was well below the physical limits, and the disk didn't seem to be thrashing.
On a hunch, I thought I'd check the disk, so I ran Disk Utility.
(Note to self: This would have been a good time to back up the data on the disk.)
Part II: The Botched Repair Job
"Verify Disk" in the Disk Utility app told me that the disk was not healthy and that I should repair it. It wouldn't let me do this on the boot disk, and told me to boot from the OS installation disk and try it again.
(Note to self: This was another great opportunity for me to back up the disk.)
Eventually (after I asked my wife) I was able to locate the install disk and booted from it (shut the computer down, power it on, hold down "c" after you hear the chime). I ran Disk Utility again, only this time the "Repair Disk" button was not dimmed out, so I clicked it, hoping that it would magically fix whatever had happened.
Repair Disk ran for a minute and then stopped and said that it was unable to repair the disk. It suggested that I back up the disk, format it, and re-install the OS.
(Note to self: This was a good time to regret having not backed up the data already.)
I could not get to the disk at this point, so I rebooted the machine normally (not from the install disk). This caused the machine to boot into the grey booting screen... and then shut off. I tried this a couple of times, and then booted with the install disk again. Once more, I was able to get into the OS, but I was not able to get to the disk (either through the UI or through the shell in a Terminal window). Moreover, the "Repair Disk" button (which had worked so beautifully the first time around) was now dimmed out again. In fact, the drive itself was dimmed out, like the system could see that there was something there, but couldn't actually mount it.
I tried running a Terminal window and getting to the disk, but it was not mounted (nothing in /Volumes), so I couldn't get there and couldn't copy the data.
(Note to self: This was when I realized that I really needed to have backed up everything several steps before.)
Part III: Go to Apple
I took the machine into the Apple Store, hoping that they'd have some advice for me.
The main thing they said was that they don't deal with personal data; as soon as the guy realized that there was data loss involved, he said there was nothing he could do. He gave me the card of a company two hours away and said that they might be able to retrieve the data for me for anywhere from a few hundred to several thousand dollars.
I love my family. And I love the digital pictures of my family that I'd apparently just lost. But I don't love them that much.
He said there was one other thing I could try, although it could risk further corruption that would make retrieval more difficult. But in case I wanted another option: boot the machine as a "target disk."
Part IV: Recovery
Booting as target disk means that you're running the computer as just an incredibly expensive external drive for some other computer. You power it on while holding the "t" key. Meanwhile, you've connected another computer to this machine via a cable that you almost certainly don't have, and the machine looks like just another disk drive to that other computer.
Details:
At this point, my bluetooth keyboard flaked out, in a combination of dying batteries and possibly confusion over bluetooth connection to a machine that didn't have a brain anymore. Fortunately, even a PC USB keyboard has a "t" key, so I was able to use that keyboard to boot into target mode.
I didn't have the cable I needed for this experiment (FireWire). Moreover, none of my other computers even have a FireWire port (newer Macs have Thunderbolt ports instead. I have a theory that they invent new interface standards every couple of years to keep cable companies in business). I ended up ordering a FireWire to Thunderbolt converter and a FireWire cable, which plugged together to connect a MacBook Pro to the dead iMac.
And ... voilà! This actually worked. I plugged it all together, booted the dead machine as a target disk, and was able to see that disk on my other computer. I quickly (okay, it took hours for this much data to travel over FireWire) copied everything I could see on that drive over to my other system and to every other disk I could lay my hands on. I hired monks to transcribe it. I transmitted the bits as smoke signals. I tattooed the binary on my body. I had my children memorize long strings of hex.
Data recovered.
The weird thing here, to me (arguably not the most knowledgeable of people about disk drive technology) is that the disk was clearly screwed up enough that it would not mount when the machine was booted with the install disk, but it was good enough to be visible across FireWire.
Whatever. I had my data back.
(Note to self: At this point, I felt like I'd cheated the system, since by rights I should not have been allowed to get my data back. But I'm okay with this. Crime may not pay, but cheating's not exactly a crime.)
Part V: Replacement
I searched for information on replacing the internal drive on an iMac and discovered that my machine/drive was actually under recall because apparently these particular Seagate drives are known to fail. So on the positive side, at least the replacement was easy and free. It's something I'd rather have known before the drive failed (apparently they do notify customers of these recalls; I may have missed that crucial memo). But at least I got the new hardware I needed, along with a clean install of my original OS.
Part VI: Back Up Your Damn Data
Now I have a working machine/drive again, and I have all (I hope) of my data on other drives. I am now ready to copy everything back and start using the machine again. But first, I'm going to figure out a backup plan. Because I know me, and if I just start using assuming I'm going to get to it soon, I'll be writing another piece in a couple of years about how I lost everything. Again.
I've polled several friends about what they do and the options boil down to these:
- Local backup
- Cloud backup
- Local + Cloud backup (for the truly paranoid, in which crowd I might now count myself)
Local backup:
There are a few options here, including:
- USB drive connected to a computer you want to back up, or a network drive connected to the network that the system is on (or at least can reach). Copy stuff manually (probably not a good idea, unless you're way better at doing this than I am), or set up some kind of automated backup solution, including the Mac's Time Machine. Note that you probably want to ensure that the backups actually happen; I had actually set up Time Machine in the past for the machine that died, but the drive decided to go to sleep and never wake up. So that didn't help.
- RAID array: This is an option on some desktop systems, where you can have disks that are essentially copies of each other, so if one goes out, the data is still alive on the other one. Swap out the bad disk for a good one and you're back in parallelizing business. This is not an obvious solution for an iMac since it only has the one internal drive.
Cloud backup:
The options that I've heard about most frequently included:
- DropBox and Google Drive: I've used the free version of these applications for a while, as a convenient way to exchange large files between computers. Recently, I've also started to use DropBox as a synchronization mechanism for some software that I use. And I use Google Drive for my various Google Docs. They both offer a small amount of storage for free (2GB on DropBox, 5GB on Google Drive). If you pay, they'll provide more storage (DropBox currently offers 100GB for about $10/month, Google Drive is about $5/month for the same 100GB).
The way these services work as a backup solution is that applications create a folder on your computer that is linked to their cloud service. You then create/copy/move anything you want backed up into that folder and it automatically syncs to the servers of these apps in the cloud. Essentially, you start using that cloud folder for all of you documents that you want to back up, and the service takes care of uploading it for you automatically.
- CrashPlan: This application is a bit more flexible; it allows you to specify various parts of your system that you want backed up and it automatically copies those items to its servers and keeps them sync'd over time. Also, it apparently encrypts the data that it uploads, so that you can feel a bit easier about your secure files that you're tossing up into the cloud. The prices vary, depending on how much storage you want, how many computers you want to back up, and how long a term you want to pre-pay.
- Carbonite: Like CrashPlan, Carbonite backs up everything you choose on a single system, encrypts it, and sends it off to the company's servers. You pay an annual fee ($59), or less per year for longer terms.
Local + Cloud
Some people are doing a combination of the above, where they have multiple local copies, but they also keep some of their core data backed up using one of the cloud services above.
I'm sure I haven't covered the full spectrum of backup possibilities here, but these are the main ones that have come up in my recent discussions with colleagues, friends, family pets... anyone that would listen to my tale of woe and help me figure out how to not fall into this pit of data Hell again.
Part VII: Conclusion
See Part VI: Back up your damn data.
Watch my video on the subject if you need more motivation.
Friday, February 8, 2013
DevBytes: Bounce Animations
Simple uses of ValueAnimator, ObjectAnimator, and interpolators to control how a shape is moved around on the screen.
Code: http://developer.android.com/shareables/devbytes/Bouncer.zip
Video: https://www.youtube.com/watch?v=vCTcmPIKgpM
Thursday, February 7, 2013
DevBytes: Any Requests?
"What is it you wanna hear?"
- Lynyrd Skynyrd
Hey #android developers:
Laundry list time. Now that I've started doing these DevBytes videos (something I've been planning on for a while now), it would be great to hear from you about tutorial topics that you would find helpful. I have a few more episodes in the can that will roll out over the next few weeks, but eventually I'll write some more apps and record shows around them, so I'm up for ideas on what you'd like to see.
Terribly important caveats:
- In general, I code/write/present around the topics of graphics and animation. These are the technology areas, and Android areas, that I'm most familiar with, and where I could be most helpful, because I might have some understanding of the issues to begin with. Having me do a tutorial on, say, location providers, or fragments, or activity lifecycle would take me more time to create something useful and probably would not result in something as useful to you.
- The whole idea of DevBytes (and most of the demos I ever write for presentations) is to be small and focused. If I have to explain, and you have to understand, unrelated bits about the application's architecture in order to understand the point I'm trying to make, I've lost. So rather than giving a tutorial on, say, the optimal architecture design for event processing in a photo viewing application, I'd rather write an app that shows how to display the photos quickly, or load them optimally, or filter them cool-ly. I've sat through presentations with huge impressive applications before, and walked away knowing nothing more than when I got there; I'd rather focus on the little things and build them up one by opne. Maybe it's just me, but that's the way I prefer to do these things.
- I'm not going to get to everything on this, or any, list. So I'm not necessarily going to get to your pet item (sorry!). The items I get to will be because of a combination of how I could contribute something useful, how I could incorporate it into an app and a show, how broadly applicable I thought the problem/solution was, what time of year it is, how warm it is, and whether I completely forgot that you requested it.
- Don't bet on this happening Immediately. It takes me a while to get to these apps, a while to set up a time to shoot the shows, a while to do the minimal post-processing that they take (mostly slapping a banner on each show and supplying a professional actor's voice, of course), and a while for them to roll out into the stream. So these are not short-term "how do you do this, I need it for my homework assignment next week?", but rather medium-term "I'd love to understand this eventually in case I have homework related to this next term" topics.
Enough constraints for you?
So, on with the ideas. Post something you'd like to see an explanation of below. If you like someone else's suggestion, +1 it to give me a [very] rough metric of its popularity (which I will use as a random filter in figuring out what to do in the future).
p.s. Don't worry if you don't have suggestions; I can always come up with some of my own, certainly enough to keep making these shows. I'm more wondering whether there are things that application developers would like to know about that I wouldn't have thought of all on my lonesome.
Subscribe to:
Posts (Atom)