Ok so this has to be among the silliest UI “innovations” I’ve encountered.
After updating my phone, Samsung Galaxy Nexus, to Android 4.2.2, I could no longer find the Developer Options menu. And here’s why … Google seems to have decided to no longer make that menu visible by default.
We can argue over why they made such a change ( my guess is to make the developer options less accessible to non-devs ) … but whatever the reason, it’s a pain.
So how to get it back ? (you’re not gonna believe this) …
- Open your settings menu
- Scroll down and select “About phone”
- Locate the entry labeled “Build number’ (probably near the bottom)
- Tap repeatedly (I believe its 7 times) on the “Build number” entry (I’m not making this up)
- As you do you’ll eventually see a message something like “You are now X steps from being a developer” … continue to tap until the “Developer Options” menu become visible.
And now you have your “Developer Options” menu back … it’ll appear on the Settings menu (screen just prior to reaching the screen with the “Build number” value)
Kind’a crazy … ain’t it
Checkout other Android Developer related information from Jim in his courses from Pluralsight.
I spend most of my time creating Android apps using Java and the Android SDK. That’s a development style that fits my experience and interests.
Fellow Pluralsight author, Shawn Wildermuth just created a course for just those folks: Practical PhoneGap. It doesn’t completely replace traditional mobile app development but does work well in a number of situations. Here’s the description from the Pluralsight website…
I encourage you to check out Practical PhoneGap.
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
How cats end up with 9 lives…
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…
A challenge commonly faced when first developing in Android is the potentially frequent destruction and reconstruction of an Activity. The most common time this occurs is when the user rotates the device between horizontal and portrait orientations.
Many an app that runs fine during testing suddenly crashes when put into a user’s hands simply because the user tilted the device one way or another.
This crashing usually occurs because device orientation changes cause the Android framework to tear down the displayed Activity along within any contained Views, and then to fully reconstruct the Activity/View hierarchy. Any references to the Activity or to the Views within the Activity suddenly become invalid. Similarly any references within the Activity or Views that were set as a result of a user action or similar are now lost.
There are a number of ways to deal with this issue but one of the easiest is to take advantage of Fragments.
NOTE: You can use the configChanges attribute on your Activity’s manifest entry to prevent the teardown/reconstruction process caused by orientation changes but that has its own headaches.
Fragments won’t automatically resolve this issue because, by default, when the Activity is torn-down in response to an orientation change the Fragment contained within the Activity is also torn down along with any contained Views.
The solution lies in an underused method: Fragment.setRetainInstance.
Calling setRetainInstance with a value of true causes Android to preserve the Fragment across the teardown/reconstruction cycle of an Activity. Along with the Fragment, the Views or other object references contained within the Fragment or Views remain.
With setRetainInstance(true) called on a Fragment instance … when an orientation change occurs, Android…
- Holds a reference to the Fragment instance
- Tears down the old Activity instance
- Creates a new Activity instance
- Attaches the preserved Fragment instance to the new Activity instance
With that, the Fragment, contained Views and object references, remain intact.
Something to keep in mind though … because your Fragment instance will be moved between different Activity instances, you should avoid caching a reference to the Activity. Instead call Fragment.getActivity anytime you need to reference the Activity.
Jim talks more about Fragments in his Pluralsight course…
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