I am super-psyched about my latest Pluralsight course now being live and available: Android Photo and Video Programming
I’m so excited about this course going live and to make it even better, the Pluralsight blog even quotes me on my excitement about this course.
With Smartphones, access to the camera is so pervasive. Don’t miss out on providing the richest possible user experience by not including camera behavior in your apps.
More posts about Android camera behavior and this latest course to come
For the past month I’ve been working on my next Pluralsight course: Android Photo & Video Programming. … I just finished recording the video for the last module.
Still have some more work to do editing the videos, preparing the course assessments, etc. but the hard work is done.
I have to say, this has been one of the most fun courses to write I’ve done. There’s something cool about taking control of the camera, rendering the live preview directly within one’s app View hierarchy and snapping a picture or recording a video.
Something I had thought was going to be a minor point that I ultimately found really interesting was controlling zoom.
The basic zoom-in/zoom-out stuff was just the beginning. Controlling the out-of-band smooth zoom and managing the callbacks that occur during the zoom process were really fun.
The course also ended having much more information than I had originally expected. I had originally spec’d the course out for 5 modules but ended up with 7 jam-packed modules – here they are…
- Getting Started
- Directly Accessing the Camera
- Viewing the Camera Preview Display
- Taking a Picture
- Camera Control
- Recording Video
- Media Store
If all goes as expected, I’ll have everything turned in to Pluralsight early next week and the course will be live a short time later. I’ll be sure to let everyone know when it goes live.
Here’s a list of Jim’s other Pluralsight Courses…
That’s right if you look at the Android Dashboard Charts for the current period (period ending April 2, 2013 as of this writing) you’ll find that the combination of 4.0, 4.1, & 4.2 devices is 54.3%.
If you looked at the chart for the previous period you find that same family of devices had only 45% of all Android devices. How does one account for such a huge jump?
Well – one way is to change the way one counts. 🙂
You’ll find the following note on the Android Dashboard Page:
Note: Beginning in April, 2013, these charts are now built using data collected from each device when the user visits the Google Play Store. Previously, the data was collected when the device simply checked-in to Google servers. We believe the new data more accurately reflects those users who are most engaged in the Android and Google Play ecosystem.
So basically .. they now count devices that actually attach to Google Play rather than counting every single device that just happens to wake up periodically and send a heartbeat to the Google servers.
So the cynic might say that Google is skewing things for their own advantage (I’m not saying they’re unhappy with this new way of counting) but I don’t really think that’s the case here.
Honestly, most of us looking at those charts are interested in seeing what versions of the platform we should target with our apps. Those apps are distributed via Google Play … so, I agree that this is the “right way” to count.
For information on creating apps for Android 4.x, checkout Jim’s Pluralsight Course
As I mentioned in yesterday’s post, I lost the ability to debug code running on my device after upgrading the device to Android 4.2.2. And as mentioned in that post, the solution was to upgrade to the latest Android Platform Tools.
Well … after checking out the Android Debug Bridge (a.k.a. ADB) docs, it turns out that what I experienced is a documented behavior.
Starting with Android 4.2.2 the platform will not allow debugging unless the user is prompted with a dialog box showing an RSA key passed from the connected desktop. This is a new security feature that assures debugging cannot be initiated on the device without a specific acknowledgement from the user.
In order for ADB to successfully make the required exchange to the device you must have a version of ADB that ships with Android Platform Tools r16.0.1 or higher installed (as of this writing the current Android Platform Tools version is r16.0.2).
So it’s a good thing but a bit frustrating when first encountered.