Jim Wilson (a.k.a. hedgehogjim)
30+ years as a professional software dev, 17+ years developing mobile solutions, Pluralsight Author, Founder JWHH, LLC
Thanks to everyone for attending the AnDevCon Tutorial and Class this week. Here’s the info from both.
You must set the user id and password constants in the GmailHelper class or the program will not work
Thank you to everyone who attended. Please feel free to contact me with any questions.
As you’ll recall, I posted yesterday about working around the issue in Android Studio where copying a project to a new folder creates problems because the Android Studio project keeps references to the original folder. After my post yesterday, I figured out an easier way to work around the problem.
You still have to modify just as many files but the steps are easier to follow and perform than my suggestion from yesterday.
We’ll use the same assumptions as yesterday.
The cool thing about this workaround is that after copying the project to the folder, you always make the same (relatively simple) changes. There’s nothing specific about the destination folder in the changes we make.
Note: I’m including line numbers just as estimates. Your line numbers will almost definitely be different.
Be sure that Android Studio is completely closed.
In both of the following files, change the value for PROJECT_ABSOLUTE_PATH to be blank
<option name="PROJECT_ABSOLUTE_PATH" value="C:\Demo\before\AndroidExampleProject" />
<option name="PROJECT_ABSOLUTE_PATH" value="" />
In both of the following files remove the full path before build.gradle (including the slash ” \ “) and replace it with $PROJECT_DIR$/
<option name="externalProjectPath" value="C:\Demo\before\AndroidExampleProject\build.gradle" />
<option name="externalProjectPath" value="$PROJECT_DIR$/build.gradle" />
<option name="path" value="C:\Demo\before\AndroidExampleProject\build.gradle" />
<option name="path" value="$PROJECT_DIR$/build.gradle" />
And with that, you’re ready to open the destination project in Android Studio.
When you save the project, Android Studio will automatically save the new folder as the PROJECT_ABSOLUTE_PATH value.
I’m finding these changes much easier to manage than the ones I walked through yesterday. But as I mentioned yesterday, the best news of all is that I suspect that this will be a short lived bug and we won’t have to deal with this workaround for long.
For information on getting started developing Android applications or working with Android Studio, checkout Jim’s Android programming courses on Pluralsight including his latest course.
Since I write training courses about Android development, I frequently have to copy projects from one folder to another. I commonly create a project in a “before” folder, copy the project to an “after” folder, and then do the work being discussed in the course in the project in the “after” folder. When students view the course they can download “before” and “after” copies of the project.
Well one of the pains I’ve been dealing with in the preview release of Android Studio is the fact that when a project is copied from one folder to another, the project keeps pointers to the original folder. One ends up with a mess where some things in the new project point to the new folder and somethings point to the old. Deleting the original folder makes things even worse.
I’ve reported the issue as an Android Studio bug. It appears to have been accepted as an issue but as of this writing the version of Android Studio currently available still has the problem.
The version available as of this writing…
I’m certain this is an issue that will be addressed so if you’re reading this post substantially beyond the posting date, verify that the problem still exists before doing the steps I list here.
UPDATE: The day after I made this post, I figured out a simpler work around. Please see this post for the new workaround.
The solution I’ve found is to modify the path information contained in 4 of the project files in the destination folder.
Before doing anything, be sure Android Studio is completely closed.
Let’s make the following Assumptions in copying our project to a new folder.
Note: I’m including line numbers just as estimates. Your line numbers will almost definitely be different.
<option name="PROJECT_ABSOLUTE_PATH" value="C:\Demo\before\AndroidExampleProject" />
<option name="PROJECT_ABSOLUTE_PATH" value="C:\Demo\AFTER\AndroidExampleProject" />
<option name="externalProjectPath" value="C:\Demo\before\AndroidExampleProject\build.gradle" />
<option name="externalProjectPath" value="C:\Demo\AFTER\AndroidExampleProject\build.gradle" />
Note: The “option” element you’re changing will be a child of the “ExternalProjectPojo” element
<option name="path" value="C:\Demo\before\AndroidExampleProject\build.gradle" />
<option name="path" value="C:\Demo\AFTER\AndroidExampleProject\build.gradle" />
<option name="PROJECT_ABSOLUTE_PATH" value="C:\Demo\before\AndroidExampleProject" />
<option name="PROJECT_ABSOLUTE_PATH" value="C:\Demo\AFTER\AndroidExampleProject" />
You may be prompted with a dialog indicating that it’s removing a non-existent project. Let it do that. It’s just cleaning up some internal data, it doesn’t appear to have any impact on the original project.
Voila! We now have a copy of our project.
The best news of all … I’m pretty sure that the bug that’s causing us to have to go through all of these steps (rather than simply copying the project folder) is a bug that will soon be fixed.
For information on getting started developing Android applications or working with Android Studio, checkout Jim’s Android programming courses on Pluralsight including his latest course.
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) …
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.
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…
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…
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.
Jim Wilson (a.k.a. hedgehogjim) 