Android App Development Keystore for Beginners

Getting into some mobile app development for Android and I was unprepared for the keystore file that is required to be included in the apk file. Using PhoneGap Build to compile my app the interface requires a keystore file uploaded.
Screen Shot 2013-02-05 at 1.55.07 PM
After some digging on google it seems that the most common way to create a keystore file is by using some Java IDE like Eclipse, but the whole reason I was using build phonegap was because I didn’t want to fool with one of those. I finally pieced together what I needed with a few posts and wanted to put it all together to help at least myself in the future.
phonegap keystore upload alias
Luckily with a mac apparently you can do this with terminal! Following a couple tutorials, I managed to create a proper file, and going through a few steps to set the expiration or validity and the alias.

To create a keystore on mac OSX, first, open terminal. We’ll type keytool and then there are some commands to type and our keystore file will be created. -genkey (generates the key), -v turns on verbose mode so full details will be output, -keystore tells it what to name the actual file (it actually saves to the root directory, I’m sure there’s a way to specify location somewhere) and you type the filename (including the .keystore file extension). Once you enter this in you are prompted to fill out your name and company name and info like city, state and country. Then it verifies everything and you must type ‘yes’. Then it will prompt twice for a password, remember this it is how you will update/rebuild your app.

keytool -genkey -v -keystore file_name.keystore

This got me going but I had to do some back and forth to know some other requirements specifically for android marketplace and working with PhoneGap. PhoneGap Build was asking for the alias when I uploaded the keystore file to build my project, but I hadn’t set one. I had no idea what it would be and after trying my name and company and even filename I had to do some more digging. We can in fact set the alias name when I create the key with the -alias command. It doesn’t matter what this is, you just have to remember it. I think of it like the username to my previously entered password. The default is set to mykey, so you don’t really need to set it. This got me through the Build process with PhoneGap, and then I set up my app on the android marketplace (after paying the $25 license fee). Once I uploaded my first apk file I was getting errors regarding the keystore again. The marketplace was telling me that the validity was not large enough. The validity (or expiration) of the key by default is set to 90 days, but the marketplace requires at least 10000 days… quite a difference, no? So to set validity we add the -validity command followed by the value of 10000. Once i did this round I re-uploaded the keystore to PhoneGap, rebuilt the app and resubmitted to the Android Marketplace and it was accepted! Wow.

keytool -genkey -alias alias_name -validity 10000 -v -keystore file_name.keystore

terminal creating a keystore file for android apk

I hope that helped someone. I’m surprised that the PhoneGap doesn’t aleviate some of the pain in this process. Since the whole point of using Build PhoneGap is so that I don’t have to set up an IDE or get complicated. A simple online keystore gen process would go a long way, and better yet if they automated it somehow!

Did I miss any steps? Are there better ways to do this? (I sure hope so) Share a comment.

Also, check out the app I made from web technologies html, css and javascript with the help of PhoneGap. It’s a quiz that tests and teaches users facial recognition of leaders at church. It’s called LDSQuiz and shows images of modern day prophets and apostles and asks you to identify them by name.

Reference links that helped me:

HTML5 Is Ready – Rebuttal to Facebook’s native app

Here’s a great “HTML5 Love Story” about the team at Sencha, who is passionate about using proper technologies for the one open web, who knew better than to trust that the failure of Facebook to create a reliable HTML5 app for users was because HTML5 wasn’t ready (as Facebook claimed). They built this demo to prove that HTML5 can do all that the now gone native FB app does and faster. The trick is you have to know what you are doing. Something it seems, FB doesn’t. Ready the full story and watch the comparison video: The Making of Fastbook: An HTML5 Love Story | Blog | Sencha. Or go try it yourself. Visit http://fb.html5isready.com on your favorite mobile browser.

When we started what became Sencha, we made a bet on the web: a bet that modern application development didn’t need anything except the browser, a great set of frameworks and a great set of tools. With those three weapons in hand, we knew developers could build applications that would delight users. The advent of HTML5 upped the game and it gave developers even more tools to let them treat the browser as an application development platform and not a page rendering engine. Developers sprang at the opportunity and unleashed a torrent of apps — on both desktop and mobile — that leveraged the new HTML5 capabilities to build amazing applications using web standards.

So, when Mark Zuckerberg said HTML5 wasn’t ready, we took a little offense to the comment.

We thought to ourselves: HTML5 can’t really be the reason that Facebook’s mobile application was slow. We knew what the browser on modern smart phones was capable of and what kind of rich capabilities HTML5 offered. We saw the latest generation of mobile devices — running at least iOS 5 or Android 4.1 — push ever increasing performance and HTML5 implementation scores. But perhaps most importantly, we’d seen what our customers were building and the amazing things they were creating using HTML5.

I totally agree with this sentiment and believe that native apps are the new flash to the web. They are fun and seem to be the way, but give it a few years and these native apps will quickly give way to web based apps that are browser based and offer speed and flexibility and consistence to the web experience. Sure, flash can do things that html still can’t. But I’m pretty sure no one would want to build their whole site in flash today. They would put the parts that need to be or the parts that belong in flash in flash and let the rest be standards compliant open web. Facebook has essentially built a flash based website for phones to access their website content. They will have to maintain and update this separate from their “real” version.

Our smart phones are helping us converge our devices, as in we no longer need a phone a camera a gps a notepad a … But it is not helping us converge our internet or content. We currently need to use a website in one way at our desk and another way on the go. Websites and the internet should have the same capabilities and the same uses no matter where we decide to use it. Sencha is showing us that, built correctly, HTML5 truly is ready to handle many things that belong in the browser rather than in a native app. We should never need to download a native app to access website data that we normally would just login at our desk. That’s inefficient, divergent and complicated. It’s against the openness and standards everyone preached and pined for and indeed “won” when flash-haters succeeded in ousting flash from mobile browsers. I actually respect Adobe for finally pulling the plug there because they too, believe in the web (and at the time, I was a full-time flash developer). I believe in the web too and that’s why I call it the one open web.

Web vs Mobile – For The User

I agree with this idea from Ryan that the web has big advantages. I am constantly hearing stats and projections that Mobile is taking over. And sure, I agree that I use my phone to browse more sites, but when it comes down to it I’m just casually browsing – not working. I love the post he’s links in the first line: Vibhu Norby has a detailed post on why his startup is pivoting from mobile first to web first.

Vibhu details that he’s done the mobile startup thing and has learned from the complications. He explains that most of these have been solved in the desktop browser already and a lot of it relates to usability.

Another big point is that mobile apps must be installed (actually they must be found, installed, opened and setup), whereas a web app can be as simple as a link- click, and then the user is already using it. Adoption is much easier on the web.

And even another point is updates and testing and whatnot. YOu can do various tests and even update the whole app relatively fast on the web. There is the one version to support – the live one. While with apps, you can’t do much in the arena of testing and updating is sluggish plus it relies on the user to update (some don’t know how to update and even less care).

I think a web app that is mobile friendly wins. You can give mobile users access, but they aren’t stuck on mobile. They can use it anywhere. While so many are talking about responsive design and produce sites that are device agnostic mobile apps are very device centric.

I’m a fan/advocate of future friendly at least, and strive for future proof (although I understand that’s near impossible). I also hold that there is ONE web and mobile myths.

Web versus Native Economics and User Adoption | Ryan Stewart – Mountaineer Coding.

Stats on a Windows 8 Game

The Falling balls app seems to be Keith Peter's "Hello World" in exploring new development arenas. Here he walks us through how his first app is trending on Windows 8.

Embedded Link

Falling Balls Update | BIT-101
At the end of October this year, Falling Balls was released into the Windows 8 Store. After just over a month, I thought it would be interesting to discuss how it is doing, and to answer the question,…

Application Cache Gotchas

A great writeup from Jake Archibald about the downfalls and downfalls to Application Cache. Having just attempted to building a mobile site using application cache, I remember hitting almost all of these gotchas and realizing that Application Cache wasn't all it made itself to seem. I resorted to actually making a mobile app rather than deal with the manifest file and it's counter-intuitive caching. This article would have helped immensely and I can't tell you how entertaining it is to read anything by Jake.

Embedded Link

A List Apart: Articles: Application Cache is a Douchebag
Good morning! Over in “castle Lanyrd” we recently launched our mobile site, which caches data on events you're attending for viewing offline. I've boiled the offline bits down to a simple demo…

Instant Install

Tired of uploading and unzipping the latest build of your favorite CMS when you start a new project? Here's a time saver, just upload one php file and click a button. Instand Install from 9miles Media (NC). It loads the latest to your server and unpacks it, then takes you to the install page to connect to the database! I was floored when I first tried it with how fast it worked. I was finding that I did this so often and got tired of waiting for all the files to upload, since I can't unzip a file via transmit, and I was searching around to find a terminal tutorial to hlep me learn to do this via the command line… But this app came up in a post and I tried it, which proves that I can continue to avoid the terminal in favor of using better designed (at least as fast) solutions. =)

Anyone have any experience with the app or any others they prefer (or even a detail to how to do it via command line)?

Embedded Link

Instant Install – Quickly and easily install WordPress, Drupal, Joomla, and more
An easier way to install web applications.

Marketing For Apps, Case Study

Here's a great case study about an app that sounds very impressive. It could have done decently on it's own merits, you say? This article describes how it was beneficial and even crucial for them to market the app to make it newsworthy, relative and successful. Some great marketing ideas here.

Embedded Link

The Art Of Launching An App: A Case Study | Smashing UX Design
The app world is becoming cluttered. The best launch initiatives are those that involve choosing strategic partners, creating clever story angles that dovetail with newsworthy occasions, and running a…

The Web Apps or Native Apps Tide

Web apps and native apps are different ends with the same mean, but they have different characteristics. I'm always a fan of the web and accessibility, but also enjoy a nicely designed app when it's useful. Here's a good thought about how Web apps are stacking up vs Native Apps and some hopeful forecasting.

Embedded Link

Web Versus Native – Asking the Wrong Questions | Ryan Stewart – Mountaineer Coding
There's been a lot of talk lately about web apps versus native. It's not that the question has ever gone away, but just over the past couple of weeks it seems like it's been called out a b…