Selasa, 05 Juli 2011

Reader Feedback: Using Your Personal Device for Development

We had an interesting comment come in from a reader recently. In our books, work, and discussions with developers and clients, we always strongly recommend testing applications on real hardware -- as much real hardware as you can feasibly get your hands on.

Why? Won't the Android code just run everywhere?

Sure, the code will run everywhere. The results, however, will not be consistent. It doesn't mean that your app will run properly or as you expect it to. This can be due to different device SDK versions, bugs in your own code, unexpected device differences (such as strange screen resolutions or manufacturer features that modify behavior slightly), and simply device firmware bugs.

Back to the reader comment:

"... because there was no mention if it would have any impact on the device.  What I mean is, will it reload all the device programs and possibly mess up my phone?"

This is a great question. Having done mobile development -- and used personal devices for testing, in addition to piles of test-only devices -- for over a decade, we often forget about such basic things. Once upon a time we worried about such issues - typically we worried most about "bricking" our phones, or causing them to become unusable.

The simple answer with Android is no, writing and deploying apps won't mess up your personal device. Well, no more so than you could mess up your device by installing someone else's poorly written app. The more complex answer is that it could, but it depends on what you're doing. If you're just loading your own applications and running them, even on the debugger, that alone won't cause problems. If you're doing something tricky with your code, going beyond the bounds of the SDK, or other lower level items, you could cause resets, instability, and even data loss -- but simply due to bugs in your code.

One caveat here is that at no time in our books or articles do we recommend rooting your device, which opens it up to higher chances of causing damage. Rooting your device gives you access to underlying systems and services that are made unavailable to developers for good reason. Yes, there can be reasons to root your device, but those who pursue this do so at their own risk. Our general feeling is that testing with rooted devices is not useful, because the majority of users in the world don't root their devices, and that's the environment our apps will run on and therefore the environment our apps should be tested on.

We do recommend backing up your data. For instance, if you're writing an app that reads and writes to the device images and you have a bunch of family photos on the device that you haven't backed up, do so. Same goes for working with contacts, etc. Maybe one of your apps accidentally deletes everything during testing. That wouldn't be any fun, would it? Therefore, your biggest vulnerability when using a personal device is the data, not the device itself.

Further, you can still use your device for purchasing items off the app stores: Android Market, Amazon appstore, and any others you'd like. Again, using a device for development does not require rooting that device, so you can still purchase books and movies that are sometimes blocked on rooted devices.

Finally, even the carriers/operators won't know or care. It's not really any different than loading apps from alternate markets. If you're developing an application that uses a ton of data over cellular connections, you might need to make sure you have a data plan that includes a lot of bandwidth, or unlimited usage, to avoid hefty fees.

Ultimately, our own personal devices are the ones we test or demo apps on the most because they are always with us and are the most convenient. We don't have to sift through boxes of cables and devices if we're using our personal devices.

Senin, 04 Juli 2011

Win a Copy of Our Advanced Android Book!


There's still time! You've got until July 8th to enter to win a copy of our advanced Android development book over at the Android Police website! Just post a comment about an app idea you've got and you'll get a chance to win one of five copies of Android Wireless Application Development, Second Edition!

We look forward to reading your comments and good luck!

(Note: This particular contest appears to available to anyone in the world!)

This book is our most recent in the Developer's Library series and is more advanced than our upcoming title, Sam's Teach Yourself Android Application Development in 24 Hours, Second Edition.

Kamis, 02 Juni 2011

Pre-Order Second Edition of Sam's Teach Yourself Android Application Development in 24 Hours Now!

Our next book, Sam's Teach Yourself Android Application Development in 24 Hours, Second Edition, is available for pre-order from Amazon. Buy it now and be amongst the first to receive it.

We've made extensive changes throughout the entire book, updating it based on feedback from readers -- including many who have commented on this blog -- as well as incorporating updates and changes to the Android SDK and tools. We appreciate all feedback; keep it coming!

We expect this book to hit shelves sometime mid- to late-August. Amazon is showing a date of August 25, while InformIT is showing a date of August 15.

We hope you enjoy it and learn from it.

Selasa, 31 Mei 2011

Win a Copy of Android Wireless Application Development, Second Edition

Android Wireless Application Development (2nd Edition) (Developer's Library)Mobiletuts+ is giving away five free autographed copies of Android Wireless Application Development, Second Edition. Find out how to enter to win one of them over on Mobiletuts+.

This book is our most recent in the Developer's Library series and is more advanced than our upcoming title, Sam's Teach Yourself Android Application Development in 24 Hours, Second Edition.

(Note: This is only available to US residents, where allowed by law.)

Senin, 09 Mei 2011

Placeholder: Details Forthcoming

This is a placeholder post.

When the reason for this post goes live, this post will be updated with all that you need to know. There is probably a better way to do this. At that time, comments will be turned on, too. ;)


Jumat, 04 Maret 2011

Reader Feedback: Analysis of an Exercise

At the end of each "Hour" in the Sam's Teach Yourself Android Application Development in 24 Hours book, there are exercises. We originally designed these exercises to be items people could try to extend their knowledge above and beyond what was learned verbatim in the chapter, given some hints and practice using the the Android documentation that is critical to become familiar with.

Here we present one such exercise that occurs in one of the first real coding hours and present our thought process for determining the solution. Hopefully this will help readers who may be struggling with the difficulty of the exercises. That said, we have also determined, based upon reader feedback, that a handful of exercises in the book are perhaps unfairly difficult. For the next edition of the book, many of these will be replaced or labelled as challenge exercises.

Walk-Through of an Exercise

This is from Hour 7 on page 125, if you'd like to follow along. As it's the end of the chapter, you already would have downloaded the code to work along with in the chapter. If not, it's available right here.
"Exercise #1: Modify the LayoutAnimationController in the QuizSplashActivity class to apply animations of each child view within a TableRow control in random order by using the setOrder() method with a value of 2 (random)."
Key Phrase #1: "Modify the LayoutAnimationController in the QuizSplashActivity"

Thought Process, Step 1: This tells me we're dealing with something to do with the LayoutAnimationController. Luckily, we just covered that on page 122, where we gave this following code:

Animation spinin = AnimationUtils.loadAnimation(this, R.anim.custom_anim);
LayoutAnimationController controller = new LayoutAnimationController(spinin);
TableLayout table = (TableLayout) findViewById(R.id.TableLayout01);
for (int i = 0; i < table.getChildCount(); i++) {
    TableRow row = (TableRow) table.getChildAt(i);
    row.setLayoutAnimation(controller);
}

Thought Process, Step 2: The code goes in QuizSplashActivity. Since I'm in Hour 7, I've been implementing this activity for the Splash Screen for most of the chapter.

Key Phrase #2: "to apply animations of each child view within a TableRow control"

Thought Process, Step 3: So far so good. The code is already doing that. We found the code in the section labelled, "Animating All Views in a Layout."

Key Phrase #3: "in random order"

Thought Process, Step 4: Hmm, I don't know how to do that. Let me read on, finishing the sentence...

Key Phrase #4: "using the setOrder() method with a value of 2 (random)."

Thought Process, Step 5: Oh, that's how! OK, hold on. I have two options: I could look up this method in the Android SDK docs, or just write it based on what was said in the exercise and see what happens. (Note: We prefer you look it up, like a good student, but experimentation doesn't hurt anything, either.) But perhaps we're lazy so... Let me just add that one line of code to the end of the initial listing, which will now look like:
Animation spinin = AnimationUtils.loadAnimation(this, R.anim.custom_anim);
LayoutAnimationController controller = new LayoutAnimationController(spinin);
TableLayout table = (TableLayout) findViewById(R.id.TableLayout01);
for (int i = 0; i < table.getChildCount(); i++) {
    TableRow row = (TableRow) table.getChildAt(i);
    row.setLayoutAnimation(controller);
}
controller.setOrder(2); // THIS IS THE ONE NEW LINE OF CODE, THE SOLUTION TO EXERCISE #1

Run the app and see what happens.... Hey! That's pretty neat. Each time I run it, the animations happen in a different order and sometimes some of them happen at the same time.

Rabu, 02 Maret 2011

Tip: Speeding Up Your Android Emulator Launch

The latest version of the Android emulator comes with a feature called "snapshots." It needs to be enabled as a feature of each AVD. Luckily, this version also includes the ability to edit existing AVDs.

First, enable the feature:

Enabling Snapshots

Second, when launching the AVD, choose to load from the snapshot and save the snapshot. When a snapshot isn't found, the AVD boots up from scratch. As we all know, this takes quite a long time even on very fast machines.

Enable Snapshot options

Now, when you exit, the system will store off a snapshot of the state of the AVD. This takes a little while, depending on how much RAM is assigned to the AVD. After saving the state once, the AVD will now launch very quickly - usually in just a couple of seconds.

However, the exit is no longer super speedy and often triggers "Not Responding" type messages. If you always want to return to exactly where you left off, this is how it will work. Overall, the behavior is much faster. However, if you want it to come up clean each time, just make sure the first time you boot it's clean, then exit to save the snapshot. Now, when you launch the AVD, only check load from snapshot, but make sure save to snapshot is unchecked.

Don't save over old snapshot

Now, the system will just load the AVD from the one snapshot you created and not save the state each time you exit. This means super speedy launches into a cleanly booted emulator as well as super speedy exits since the snapshot doesn't have to be saved each time.

You'll start to feel like you don't need to keep the emulators running all the time. You also won't necessarily go looking for a phone each time just to save the emulator boot-up time. (You'll still go after the phone or tablet when debugging for performance or with code bases that are otherwise slow on the emulator or other such reasons.)

How much difference does it actually make? Here are some test results running on a 6 core 3 GHz desktop with 8GB of RAM and a relatively speedy SSD:

  • Cold launch of Android 3.0 emulator to a usable state: 4 minutes 35 seconds
  • Snapshop launch of same Android 3.0 AVD: 8 seconds

That cuts the emulator launch time by 97%. Put another way, the cold launch takes 34 times longer. Taking these steps is well worth the minimal additional effort.


Happy Android Coding!
ANDROID BOOK © 2008 Template by:
SkinCorner