I like getting email from readers of our "Pro Android" book series, especially when they're raving about our book ;-) I received an email just yesterday from a reader who asked if there was some sort of repository of Android knowledge, for things like the following:
Having a focusable item in a row of a ListView CAUSES the
OnItemClickListener to NOT be invoked, like an AUTO-LINK.
We'd all love to see such a repository, but I'm not aware of one place where you can get all the answers. I think that's mostly due to the pace at which Android is being developed. For example, I was very surprised to see that in release 2.3.3 (Feb 2011), they deprecated some NFC API methods that were brand new in release 2.3 (Dec 2010). The fragment compatibility library had some significant bugs in it when it was released, which tells me Google doesn't do a very good job of testing all their stuff. The documentation is sometimes rather terse, sometimes missing and sometimes wrong. Ideally there would be no need for a separate repository of knowledge; everything would work as documented, and the documentation would cover everything. Yes, it can be very challenging to be an Android developer if you want to do something interesting with it.
You can imagine what it's like to write a book the size of Pro Android (1139 pages in Pro Android 3). Our sample applications can sometimes take a while to finish because we often run into strange behavior which we feel compelled to figure out for our readers. So we scour all over for the answers. Satya's methods may be slightly different than mine, but here is where I go for information (not necessarily in this order):
1) Google search. Of course, right? I'd say it's an art form to get a search string just right, but there are so many places out there with little Android tutorials, or sample programs, or forums. Sometimes you get lucky and find the answer. Sometimes I find that other people have the same question but no one has the answer. For me, the best search is to take a significant portion of the error message reported in LogCat. The more keywords in your search, the more likely you'll hit a relevant page.
2) Forums. There are many, many forums for Android developers to share information. LinkedIn alone has several but I don't get much value out of them. I've never posted questions to any of them but I've posted a few answers. Stackoverflow.com is pretty good. It's also known as "Android Beginners". There are lots of already-answered questions, and a fair number of people who post answers. In any forum, it's important to include as much relevant information as possible, including links to screenshots, or stack traces. Another forum that's good is android-developers (http://groups.google.com/group/android-developers/topics). Good questions on this forum can even get answered by the Android team at Google (Dianne Hackborn or Nick Pelly or Romain Guy for example). There are several experts who also post answers, but again, it's important to ask a good question and to have a good topic line to catch their eye. Posts with a topic of "Newbie needs help now!!!!" won't likely see any response at all. Better to post "?? Focusable item in a ListView row CAUSES the OnItemClickListener to NOT be invoked??". If your question is specific to a device, most manufacturers also have developer forums and employees providing answers.
3) ApiDemos. This is in the set of sample apps that are downloadable just like the Android SDK. If you haven't checked these out yet, you should. It shows you how to use many of the Android APIs. In some cases it answers questions on how to do things. Other times it just raises more questions. But since you have the source code and you have an app that you can run, it's possible to read the source, debug it, etc. You can import these in the New Android Project wizard. Just choose "From samples" and select ApiDemos.
4) Android SDK source code. There are a few places to go to to see Android source code. At the moment, Android 3.x source code has not been released by Google, so the best you can get now is 2.3.5. This is a good starter page: http://source.android.com/ and this is where you can view source online: http://android.git.kernel.org/ The fragment compatibility library for the pre-3.x versions of Android comes with source code. To find it, look under your local Android SDK directory after installing that library using the Android SDK and AVD Manager.
5) Google I/O online videos. The next best thing to being there, the videos have great information from the engineers creating all the Android goodness.
6) Tinker. Experiment. Try different approaches. Reduce the problem to code as simple as possible. Use the debugger and set breakpoints, then inspect the variables. Repeat. Start with code that works, then modify it towards what you want it to do, testing with each step to see where it stops working.
Hope this helps! And if you find that magic repository, be sure to let us know ;-)
Saturday, August 13, 2011
Sunday, July 31, 2011
Success! My Toshiba Thrive is now talking to my computers!
I'll say it again: it shouldn't be this hard. Toshiba really needs to provide better and more complete information to help a developer setup a Thrive tablet to work with Android's adb server. With that out of the way, here is what I found to work for me, and what I'm describing should work for anyone with any Android device.
For my Windows PC running XP, this page held the answer. But be sure to read the comments, especially those of Dan and HMishkoff. The value to be used depends on the vendor of your device. There is a nice list of all the vendors here.
So that got me up and running with Windows, so I turned next to my Ubuntu Linux box. That setup is rather different, but not too difficult either. Fortunately, the USB drivers are already there. What needs to be done is to configure the udev rules file which should be created (or modified if it exists), in the /etc/udev/rules.d directory. This page has pretty good instructions which worked well for me.
Scroll down to the comment from jerichod. It's brilliant! Not only does he tell you how to modify the .rules file, he gives you the background and a couple of commands to make it so much easier to figure out. So I took his work and created a rules file with all currently-known vendors in it, and made it available here.
All you should need to do is copy this file to /etc/udev/rules.d, modify the owner and group values to what is suitable on your machine, save the file, then connect your device using USB. This last part is critical and tripped me up for a while. It's also not mentioned in the above instructions. After you change the .rules file, you need to connect the device for udev to use the new values from the file. If your device is already connected when you change the file, you need to disconnect it, then connect it again.
And that should do it! For anyone with a Mac, it's supposed to just work. I'll try that later, and if it doesn't just work, I'll post a follow-up with those instructions.
For my Windows PC running XP, this page held the answer. But be sure to read the comments, especially those of Dan and HMishkoff. The value to be used depends on the vendor of your device. There is a nice list of all the vendors here.
So that got me up and running with Windows, so I turned next to my Ubuntu Linux box. That setup is rather different, but not too difficult either. Fortunately, the USB drivers are already there. What needs to be done is to configure the udev rules file which should be created (or modified if it exists), in the /etc/udev/rules.d directory. This page has pretty good instructions which worked well for me.
Scroll down to the comment from jerichod. It's brilliant! Not only does he tell you how to modify the .rules file, he gives you the background and a couple of commands to make it so much easier to figure out. So I took his work and created a rules file with all currently-known vendors in it, and made it available here.
All you should need to do is copy this file to /etc/udev/rules.d, modify the owner and group values to what is suitable on your machine, save the file, then connect your device using USB. This last part is critical and tripped me up for a while. It's also not mentioned in the above instructions. After you change the .rules file, you need to connect the device for udev to use the new values from the file. If your device is already connected when you change the file, you need to disconnect it, then connect it again.
And that should do it! For anyone with a Mac, it's supposed to just work. I'll try that later, and if it doesn't just work, I'll post a follow-up with those instructions.
My new Toshiba Thrive Android tablet
I now own an Android tablet, a Toshiba Thrive to be precise. I've used an iPad 1 before, but this is my first Android tablet. There are some things I really like about it, such as the maps and turn-by-turn navigation (even though this is just a WiFi model). However, there are a couple of things that I don't like at all.
The first big problem is the not-waking-from-sleep problem, that appears to afflict many Thrives. Lots of complaints voiced online, no solutions from Toshiba, yet. Very surprising since it's a basic function that really ought to work if you're going to ship the product. The latest news is that an update will push out next week to fix this. Let's hope so.
The bigger problem, from my point of view at least, is that I cannot easily get it to talk to my Android development environment on Windows XP. And here's where I'm starting to worry: I found a little tidbit of information on the Toshiba site http://tabletsupport.toshiba.com/ that said Toshiba does not support the SDK and doesn't plan to. Uh oh. I'm scouring the web for helpful tips and think I may have found a few. Also, I have Ubuntu and MacOS here at the house so might be able to get it working with a different computer.
More news later...
The first big problem is the not-waking-from-sleep problem, that appears to afflict many Thrives. Lots of complaints voiced online, no solutions from Toshiba, yet. Very surprising since it's a basic function that really ought to work if you're going to ship the product. The latest news is that an update will push out next week to fix this. Let's hope so.
The bigger problem, from my point of view at least, is that I cannot easily get it to talk to my Android development environment on Windows XP. And here's where I'm starting to worry: I found a little tidbit of information on the Toshiba site http://tabletsupport.toshiba.com/ that said Toshiba does not support the SDK and doesn't plan to. Uh oh. I'm scouring the web for helpful tips and think I may have found a few. Also, I have Ubuntu and MacOS here at the house so might be able to get it working with a different computer.
More news later...
Wednesday, May 25, 2011
A new metaphor for securing corporate data on consumer devices
The growing trend of personal devices being used for company business needs a new metaphor: digital rights management (DRM) for corporate data. Given the history of DRM in the music industry, does this mean we're doomed?
I work for a large company in Jacksonville, FL. A company that has to be very careful with data about our customers. If our employees make mistakes, it could result in jail time. I'm in IT, and I appreciate that we want to go to significant lengths to protect our customer data from "getting out". It's just bad for everyone if that happens. At the same time, I see the growing trend of employees wanting to be able to use their personal devices for work. A personal smartphone, or tablet can make a person much more productive when they're not at their desks. This could be in meetings, or at lunch, or anytime outside of work hours. The problem is that personal devices provide a lot of freedom to the owner. Freedom to choose just how secure the device needs to be. The default settings are often extremely lax, no security at all. No password to unlock the device, no encryption of the data on the device. This makes the device really easy to use. And a potential catastrophe if sensitive corporate data were there for the taking.
The methods currently in use for protecting corporate data fall into two main camps: lock down the device entirely, or lock down a portion of the device where the corporate data is supposed to be stored. The former usually means the company owns the device, controls the administration of the device, and severely restricts the user in terms of their freedoms to choose their level of security. Password policies are enforced to make sure strong passwords are always in place, encryption of data is the only option, installation of apps is restricted or prevented. The device really isn't a consumer device anymore at all, it's a corporate device. RIM has made a lot of money in this space and for good reason. Companies will pay for the productivity gains and for the piece of mind that comes with the control. The other option seems to be products like Good Technologies, in which a piece of software installed on the device provides the security measures, gives control to the company, and sandboxes the corporate data so the "bad guys" can't get to it. If the device is lost or stolen, the company can prevent anyone from getting to the company data. The rest of the device can be whatever the user wants it to be. This is a respectable tradeoff, but still limits what a person can use their device for with respect to work. If the "sandbox" app doesn't do a certain business function, the user can't use their device for that business function.
I thought of a new way to think about the problem, and it got me wondering if it might help solve the problem. In my mind, the problem is controlling access to the corporate data, regardless of what application wants to see it, create it, modify it, search it. In a similar way to how the music industry wants to control access to music content, companies want to control access to corporate content. What we need is digital rights management (DRM) for corporate data. How successful has DRM been for the music industry? Not so good. The movie industry? Uh, no. Should we think that DRM for corporate data is going to fare any better? Well, maybe. Because it's got to. And the solution cannot be that we sue everyone who somehow gets access to our sensitive data.
I think there are lessons to be learned by thinking about protecting corporate data like we hope to protect music, movies and books. It is too damn easy for pirates to make available copies of copyrighted material. We've tried mechanisms and failed. We've got to keep trying. We may never be done, but we must continue to raise the bar ever higher.
I work for a large company in Jacksonville, FL. A company that has to be very careful with data about our customers. If our employees make mistakes, it could result in jail time. I'm in IT, and I appreciate that we want to go to significant lengths to protect our customer data from "getting out". It's just bad for everyone if that happens. At the same time, I see the growing trend of employees wanting to be able to use their personal devices for work. A personal smartphone, or tablet can make a person much more productive when they're not at their desks. This could be in meetings, or at lunch, or anytime outside of work hours. The problem is that personal devices provide a lot of freedom to the owner. Freedom to choose just how secure the device needs to be. The default settings are often extremely lax, no security at all. No password to unlock the device, no encryption of the data on the device. This makes the device really easy to use. And a potential catastrophe if sensitive corporate data were there for the taking.
The methods currently in use for protecting corporate data fall into two main camps: lock down the device entirely, or lock down a portion of the device where the corporate data is supposed to be stored. The former usually means the company owns the device, controls the administration of the device, and severely restricts the user in terms of their freedoms to choose their level of security. Password policies are enforced to make sure strong passwords are always in place, encryption of data is the only option, installation of apps is restricted or prevented. The device really isn't a consumer device anymore at all, it's a corporate device. RIM has made a lot of money in this space and for good reason. Companies will pay for the productivity gains and for the piece of mind that comes with the control. The other option seems to be products like Good Technologies, in which a piece of software installed on the device provides the security measures, gives control to the company, and sandboxes the corporate data so the "bad guys" can't get to it. If the device is lost or stolen, the company can prevent anyone from getting to the company data. The rest of the device can be whatever the user wants it to be. This is a respectable tradeoff, but still limits what a person can use their device for with respect to work. If the "sandbox" app doesn't do a certain business function, the user can't use their device for that business function.
I thought of a new way to think about the problem, and it got me wondering if it might help solve the problem. In my mind, the problem is controlling access to the corporate data, regardless of what application wants to see it, create it, modify it, search it. In a similar way to how the music industry wants to control access to music content, companies want to control access to corporate content. What we need is digital rights management (DRM) for corporate data. How successful has DRM been for the music industry? Not so good. The movie industry? Uh, no. Should we think that DRM for corporate data is going to fare any better? Well, maybe. Because it's got to. And the solution cannot be that we sue everyone who somehow gets access to our sensitive data.
I think there are lessons to be learned by thinking about protecting corporate data like we hope to protect music, movies and books. It is too damn easy for pirates to make available copies of copyrighted material. We've tried mechanisms and failed. We've got to keep trying. We may never be done, but we must continue to raise the bar ever higher.
Tuesday, March 22, 2011
Introduction
Technically this is my second blog post. I had chosen a name for this blog, then later realized that it was probably the 36th blog to have that name (Eschew Obfuscation) so decided I needed a blog name that wasn't already taken. This one seems unique enough. At least for now.
I plan to write articles about Android mostly. Our latest book "Pro Android 3" is over 1000 pages, but still we couldn't fit everything in that we wanted to. So between this blog, our website www.androidbook.com, magazine articles and posting to the android-developers group and stackoverflow.com, I hope we can help the Android cause. And have some fun while doing it.
I plan to write articles about Android mostly. Our latest book "Pro Android 3" is over 1000 pages, but still we couldn't fit everything in that we wanted to. So between this blog, our website www.androidbook.com, magazine articles and posting to the android-developers group and stackoverflow.com, I hope we can help the Android cause. And have some fun while doing it.
Subscribe to:
Posts (Atom)