New eBook – Google App Inventor
December 12, 2011 by dave@kiwiluv.com · 1 Comment
I was given a nice opportunity recently to have a look at a review copy of a new book on Google App Inventor that Pakt Publishing kindly provided. The book, Google App Inventor by Ralph Roberts, is deadly serious about teaching you just about everything there is to be known about Android development using Google App Inventor.
The book weighs in at 356 pages for the PDF version (ePub and print also available), so although it’s a beginner’s guide it takes you pretty far down the path.
Last year, I posted my take on the App Inventor beta. A lot has happened in a year with App Inventor, but first the book…
In The Beginning
The book starts out with the obligatory installation sections. However, the level of detail is excruciating, so there is absolutely no chance that you won’t be able to install the App Inventor applications on your computer. It’s also refreshing to see that all three of the major platforms are given equal footing (I admit that some of my own stuff may be a bit Mac/Linux centric).
Moving on, the basics of blocks and the available components are presented. There is definitely no glossing over subjects, so the introductory chapters will give the reader a firm grounding in what you can do with the App Inventor environment. It even has a “Not Ready for Prime Time” section to tell you what parts of App Inventor may not yet be fully baked.
In the Part Just After the Beginning but Not Quite the End
From there, the author divides the topics up by flavors of app, which I quite liked. Those are…
- Apps that Communicate
- Apps that Remember
- Apps that Surf the Web
- Apps that Know Where They Are
- and finally Games and Animation
If I had written this book there would also be an “Apps that Mysteriously Crash” section. Fortunately I didn’t.
In these chapters, the reader is guided through building apps that fall into these categories. For example, an “App that Surfs the Web” that is built is an eBay link app which shows how to use App Inventor to fetch and present web content. Although a specific example is presented in each of these chapters, they are great examples of the techniques to use in each specific problem domain.
The Appendices
The problem with books is that inevitably when you publish them, something changes. Packt and the author were not shy about tacking this late breaking information onto the book to ensure that it’s as complete as possible. There are also pointers to a load of resources for the aspiring App Inventor guru in the appendices.
But didn’t Google Kill App Inventor?
Nope. It’s true that under Larry Page’s new regime Google is cleaning house and ridding themselves of products which are not core to where they want to go (wherever that is). Yes, App Inventor is one of those, however Google did not shut App Inventor down. Instead they handed stewardship of App Inventor to the Center for Mobile Learning at the MIT Media Lab. That’s a good place for it. The center is brand, spanking new having been launched in August of 2011.
The book includes this late breaking tidbit in the “Final Last Minute Update” appendix (not to be confused with the earlier “Last Minute Update” appendix and presented the full text of the App Inventor news from Google, which I also received as an App Inventor developer. Here it is.
Dear App Inventor User,
As a result of the recent changes to Google Labs and App Inventor, effective immediately, the URL for App Inventor will change from appinventor.googlelabs.com to appinventorbeta.com. This URL change will not have an impact on your projects stored in App Inventor. All data that you see in your appinventor.googlelabs.com account, as well as documentation and e-mail forums, will be available at appinventorbeta.com.
As we announced on the App Inventor Announcement Forum, Google will end support for App Inventor and open source the code base at the end of this year. Additionally, in order to ensure the future success of App Inventor, Google has funded the establishment of a Center for Mobile Learning at the MIT Media Lab, where MIT will be actively engaged in studying and extending App Inventor. This transition will happen at the end of 2011. At that time, you will need to download your data from appinventorbeta.com in order to continue working with it in the open source instance of App Inventor. In the coming months, we will send
you detailed instructions on how to download your data. Please visit the App Inventor user forums to get future updates on App Inventor.
The App Inventor Team
I’m pretty sure App Inventor will find a good home at MIT.
Summary
My previous stand on App Inventor hasn’t changed. I think it’s a great platform for learning programming and getting into Android development. As a teaching tool, it illustrates flow control and other aspects of programming logic without the burden of having to choose and learn a specific language. I still prefer the ancient ways of typing in code, however for those willing to embrace the new and shiny, this book is probably the most thorough grounding in App Inventor available.
Day One with the HTC Thunderbolt
March 19, 2011 by dave@kiwiluv.com · 1 Comment
I mentioned in a previous post that my 2nd Motorola Droid was wiggin’ out by registering random touches on it’s touchscreen, making the phone almost unusable. This is the second time with the same failure, so I’m done with Motorola for the time being. This happened about a month ago, but I decided to suffer through waiting for Verizon Wireless to release their first 4G LTE phone, the HTC Thunderbolt. Although no formal release date was every mentioned by VZW, the Internet went crazy with release date rumor mongering.
On St. Patrick’s Day, March 17th, the wait was finally over. Oddly enough, even though I signed up on Verizon’s site to be emailed when the phone was available, I never got a notification. Thanks for that Verizon.
I showed up at the Verizon store near work and was apparently the first customer to buy one even though I wasn’t first in line. Since I was their first customer, they made me pose for a picture with my new phone and sign a release. I’m currently living in fear of that photo showing up somewhere…I guess I’d better check out Verizon’s Facebook page.
So, after a couple of days, here are some first impressions.
The Hardware
The phone is hefty and extremely well built. The screen is beautiful and playing Angry Birds on it is a lot more fun than on my smaller Droid (boring meetings just fly by during the day while killing those evil pigs). The phone has a 1.6MP front facing and 8MP rear facing camera. The case has a nice rubberized surface on the back, but be careful anyway because given it’s size and heft it’s still easy to loose if you’re not careful. It was a bit freaky watching the SIM card get installed. A Verizon phone with a SIM card? Never thought I’d see the day.
Probably my favorite feature (although I’ve yet to use it for any practical purpose) is the kickstand which is pictured above. I took a video with the main camera and got decent results, although I don’t expect much from a smart phone.
Here’s a video of our recently rescued beagle we found wandering the arctic tundra during our heavy snows a month or so ago.
I thought that the frame rate was a big jerky, but it seemed adequate for a phone.
General Performance
The screen response is amazing in contrast to the Droid. Applications launch quickly and paging around is very fast and responsive. I did encounter a few quirks that bothered me.
- I downloaded Pandora and was listening to it through my car’s bluetooth audio after having paired the phone to the handsfree. Since then, whenever the handsfree is used with the phone, Pandora starts streaming automatically.
- Battery life is bad. On the first couple of days I’ve been playing with it exessively I admit, but it required a recharge mid-day. There were rumors that the “delay” in releasing the phone was due to problems with battery life. When I picked up the phone, the VZW person helping me scampered back to the secret vault and came back with an email from another store suggesting that the persistent data connection bet turned off to significantly improve battery life. He mentioned that they’d been getting emails from other stores all day sharing experiences and tips with this phone.
- The GPS takes significantly longer to get a lock than my Droid. However, I should note that the Droid had a strangely quick GPS lock and often worked indoors for me. I think that the Thunderbolt has more typical performance for a GPS receiver in a phone.
4G LTE Network Performance
With a 4G connection, browser performance is amazing. The phone switches to 3G or whatever data link is available. While using navigation recently in the middle of nowhere with bad coverage, I did notice that it appears to take a bit longer if the phone has to switch data networks constantly.
We are in the Philadelphia metro area and until I got out into the uncharted areas of Pennsylvania, 4G coverage was good and 3G was around almost everywhere else, so as long as the phone can gracefully switch there are no worries there. Still, it would be nice to lock it into 3G mode if you know you’re out of 4G coverage areas.
Verizon – Rule the Air (with Crapware)
My Motorola Droid was a pure, out-of-the-box Google Android experience. Sadly, the HTC Thunderbolt from Verizon is polluted with crapware including a Blockbuster app which will probably soon be the last remaining vapor of Blockbuster memorialized for all eternity on my phone. Of course you can’t uninstall any of this stuff without rooting the phone.
Still, given the outstanding coverage and speed I guess I’ll come to terms with the preinstalled debris.
Final Thoughts
I love the phone. I hate the battery life and it clearly has some quirks. But remember, this is a completely new device on a new and unproven network. I expect it’s going to be a firmeware update or two before some of the warts are removed. I applaud Verizon for aggressively rolling out the LTE network. Hopefully soon the US will join the rest of the world with GSM and LTE coverage everywhere.
Since we do development for these I can justify being an earlier adopter. Typical consumers may want to wait for a later generation or at least a firmware update or two before taking the plunge.
Time for a New Phone – HTC Thunderbolt?
February 23, 2011 by dave@kiwiluv.com · Leave a Comment
Well, I’ve had it with my original Droid. For the second time it’s been infested with poltergeists and the touch screen if whacked out. I hope it didn’t send too many unintelligible emails and text messages during one of it’s seizures. I stopped by Verizon to see how things look with the HTC Thunderbolt. They’re speculating that despite rumors that it would be available on the 14th, then the 24th and then the 28th I was told that they’re hoping they can release it Thursday, so guess we’ll see tomorrow.
Stay tuned for my report on whether it’s infested with crapware like the Samsung Fascinate on Verizon is.
Look at Android 3.0 – Honeycomb for Tablets
January 6, 2011 by dave@kiwiluv.com · Leave a Comment
CES 2011 is going on and here’s an eerily silent video of the new Android 3.0 Honeycomb UI. This is the version of Android which better supports tablet form factor devices. This will certainly be an interesting year in tablet-land and I’m looking forward to doing some development for these. This particular one is LG’s G-Slate for T-Mobile.
Smart Phone GPS Quality
December 29, 2010 by dave@kiwiluv.com · Leave a Comment
These guys are pushing smartphone GPS capabilities to their limit. The typical consumer may not notice, but there’s a wide quality variation among iPhones and Android devices…check it out on David Lokshin’s blog. He’s uncovered the dirt that Steve Job’s will never speak of…
Motorola Tablet – Android (Honeycomb) Powered Tablet?
December 24, 2010 by dave@kiwiluv.com · Leave a Comment
Motorola’s marketing guys released this last week. Apparently they’re going to announce a black curtain at CES this year. Last CES was filled with tablet announcements that never launched. This year, some might actually make it.
Judging by the tags associated with this, it will run Honeycomb, the tablet optimized version of Android. A few other manufacturers are rumored to be ready to go. They took a jab at the iPad for being just a giant iPhone. Somehow that works. I used the Samsung Galaxy Tab, and somehow that one works as well with a “non-tablet” version of Android. I’m more excited to see Honeycomb than any particular tablet. In Motorola’s case, their mobile hardware has been evolving from a giant pile of suck to a slightly smaller pile of suck recently, so I hope this tablet continues that trend.
Android Location Services – Proper Care and Feeding
December 20, 2010 by dave@kiwiluv.com · Leave a Comment
Nothing will kill your battery faster than running the GPS receivers all the time on an Android phone. I was planning to do a post showing how to properly suspend location updates when they are not needed to conserve battery life on Android. However, I stumbled upon this post on the Dev Discoveries blog which pretty much says it all. In general, to optimize battery life any intensive services that aren’t needed should be shut down when the app is suspended. Remember, Android has no single “Quit” event for an app, but rather a complex series of state changes forcing you to decide what to do in each case. Check out this post here on implementing handlers for these application state transitions.
Thanks to Dev Discoveries for the great info.
Email Attachments from Android Apps
December 16, 2010 by dave@kiwiluv.com · 5 Comments
Here’s a less ranty Android development post than my last hissy-fit about external storage. From an Android app, it’s pretty easy to invoke the email application to send something by using an Intent. If you search the Internet, you’ll see that there are a ton of folks having trouble with attachments in this situation.
I just got this to work and thought I’d share the fun. Unlike my SD Card rant where the proper way to do things is easily found, programmatically adding an attachment to an email is tougher. The examples out there don’t always work and there are little traps everywhere.
The Basics
Ok, here’s how I did it. First I implemented the following method in my main activity.
private void emailFiles(String file) {
Intent sendIntent = new Intent(Intent.ACTION_SEND);
sendIntent.setType("application/zip");
sendIntent.putExtra(Intent.EXTRA_STREAM, Uri.parse(file));
sendIntent.putExtra(Intent.EXTRA_SUBJECT, "AlpineReplay Data File");
sendIntent.putExtra(Intent.EXTRA_TEXT, "AlpineReplay data file attached.");
sendIntent.putExtra(Intent.EXTRA_EMAIL, new String[]{email.trim()});
startActivity(Intent.createChooser(sendIntent, "Select Destination"));
}
Which I call from a menu selection thusly…
emailFiles(zipFilePath);
Where zipFilePath is the path of a zip file I want to attach (seriously people…keep up) passed as the file argument. However the format of this is pretty important. It is passed to the function looking something like this:
file://sdcard/myappname/data/myzipfile.zip
In other words, the absolute path to the file. Here’s the two magic things to look out for.
First, you’ll see a bunch of examples on the internet showing exactly this string as the argument for sendIntent.putExtra() for the content, but this may not work in all cases. Intent.EXTRA_STREAM should be given a properly formatted URI, which is why it looks like this in the example above.
sendIntent.putExtra(Intent.EXTRA_STREAM, Uri.parse(file));
That puts it in the form of a properly formatted URI (probably changing file:// to file:///…gotta have that third ‘/’ on Linux systems like Android or the files will get lost).
The second nuance I discovered was in this line:
sendIntent.putExtra(Intent.EXTRA_EMAIL, new String[]{email.trim()});
What the heck is that trim() crap all about? In my case, there was a newline after the email address I got from a EditText control. But you could get other cruft such as trailing whitespace, so trim(), which is a String method, will get rid of it all. I don’t know about all apps that accept file names from an Intent, but gMail can’t deal with those characters and will complain that it’s an invalid email address.
Just one more comment. The SendIntent will cause a chooser to pop up with a list of applications capable of handling the attachment. In my case that’s gMail, Bluetooth (file transfer), and DropBox. If you don’t want those options you may need to whittle it down to just the one you want when you create the chooser.
Xfinity’s at it Again – Android App
December 15, 2010 by dave@kiwiluv.com · Leave a Comment
Looks like Xfinity’s been busy. They released an iPad app a month or so ago, and now and Android app just appeared. I played with it and like the iPad app, the UI is nice. The back office piece supporting the app isn’t quite there yet (that’s a tough one for most MSOs to solve), but I give them credit for releasing it into the water supply with a few warts rather than keeping it in the incubator forever. Check it out…I’m sure it will evolve into something pretty cool.
Rant on Application Files in Android
December 14, 2010 by dave@kiwiluv.com · 2 Comments
I was working on an Android app recently that made heavy use of file storage on the SD card. This required that I browse the SD card using DDMS, shuttle files around, etc. I was appalled to see the amount of residue and cruft that was littering the SD card on my poor Droid. It was like a ghetto in there, only not quite as scenic.
I had spent a stint at a small enterprise which had outsourced a lot of Android development (remember, people on the outside always look smarter which is why consulting is such a good career choice). The developers ranged from offshore code factories in India and Russia to some of the leading research universities in the US (a much lower bar than one would hope). Without exception, not one of them knew how to handle the Android file system properly. Although I had long since deleted every single app from this job, their foul stench remained on my poor SD Card.
So, for the sake of posterity here’s what to pay attention to.
Be a Good Citizen
Sometimes I think the barrier to entry for mobile app and lately web development is too low. It’s too easy to throw an app together without really knowing what you’re doing. On a mobile device, you’re sharing battery life, memory, SD card space, screen real estate, and many other scarce resources with the OS and all of the other apps on the device. In the file system, Android has conventions and has recently updated the API to support playing nice in the SD card sandbox with everyone else. And yet, sadly, nobody seems to care, resulting in storage capacity being slowly eaten up by useless files from long uninstalled apps.
Dave’s SD Card Rules
As a public service, I’m establishing some rules for using external storage because, clearly, the Android API documents are too polite and subtle. So, much like those at a swimming pool, here’s my rules you should follow for playing in the external storage of your Android device. Failure to do so will result in your app’s immediate expulsion from the SD card.
This list was inspired by everything that I had to clean up (with very strong bleach) in my SD card.
- DO NOT save application files at the top level of the SD Card directory (more on this later). Do not even create an application subdirectory there…that’s not where it goes. If you do so, I will find you and take your microSD card away.
- DO NOT hard-code file paths to the SD Card root directory. The Android operating system is very helpful (usually). Ask it where it is and believe what it tells you. Failure to do so will result in your app not working across devices. Read all about it in Environment.getExternalStorageDirectory(). In fact, read this entire API section. You will find that there are state checking calls to make sure the external storage is actually there plus many other useful things you can find out to make your apps less stupid. Use it and your apps will be a much smaller pile of suck than they probably are now. Not checking media state before using it is like jumping into the pool without making sure there’s water in it, forcing me to mop up your entrails and break out the very strong bleach again.
- Speaking of mopping entrails, clean up after yourself. Temp files should be deleted. Following rule #4 will allow the operating system to clean up your apps remains after it is uninstalled.
- Follow the API guidance on where to allow your app to write files (aka crap) in the external storage (aka my pool). Here’s what it says…just do it!
Pretty clear, huh? So let’s all take a break and study up a bit on how this stuff actually works instead of pasting code examples from the Internet into your apps all day. Please STOP BEING SUCH FRIGGIN AMATEURS!!!!
Ok…rant over…back to work…nothing to see here. Once I calm down and buy a new SD Card to replace the one I bit in half, I’ll post some more useful examples of how to peacefully coexist on the Android platform. Until then, sudo rtfm.