This is part three in the series How to Build an Android App in a Week.

Now that we have an idea of how Android works, we can start designing the app.

As I stated in my last post, I found viewing Activities as logical divisions with discrete entry and exit points the most intuitive. Capitalizing on that, I will center my design around that.  BUT WHAT AM I DESIGNING.

WHAT IS HE DESIGNING?

When looking at what I want to make, I settled on a few axioms:

• I want something people will use
• It needs to be small enough to complete in a week
• It can’t be anything too “cool,” or else it won’t get completed/people won’t use it.

I want something people will use, so I looked at what I’d really like to use.  In about a month I’m going on a trip for a few weeks, and I’ve noticed keeping in budget can be pretty difficult.  Whether it’s spring break, a weekend trip, or a holiday vacation to mom n’ pop’s, it’s hard to have a concrete idea of how much I can spend today, tomorrow, or any other day and stay in the sweet-spot.  Overspending is bad, but underspending is even worse.  JUST THINK OF ALL THE FUN YOU MISSED WHEN YOU COME HOME WITH MONEY.

Building on that, it needs to be small enough to write in a week (or just 3 more days, AAAAGGHH!).  Luckily, this is in harmony with “something people will use.”  Features should be minimal, and the app should be streamlined to make entering costs as easy as possible, so you don’t need to drop out of the action too long to keep it up to date.

Last, it can’t be too “cool.”  I’ll just have to keep this in mind as I’m thinking about all those dream features.

Thinking about all of the above, I settled on some bullet-points:

• The app shouldn’t get in the user’s way.  Input should be validated as soon as it’s input, so the user can see in real-time what he’s entering. Second, except for the cost, every other field should be optional.
• Trips should be easy to set up and intuitive. That means as few fields as possible.
• The app should be easy to manage.  This means that when the app fires up, it should read the user’s mind.  Ideally, it should open up the last accessed trip on the current day, so checking your budget is immediate and entering new expenses is just a number and a button press away.

Building on this, I have for a Trip object:

• A start date (mm/dd/yy)
• An end date (mm/dd/yy)
• A budget
• minimum daily amount, which is the minimum amount necessary to live on in a day.

That last one bears some explanation.  Minimum daily amount is the minimum amount you need to get through a day of the trip.  This includes travel expenses, food, and whatever else.  It should be just a little generous.  This’ll prevent someone from inputting a future cost that wipes out all their money for the day.  For example, if your taking a week-long trip, your budget is $700, you’ll have a budget of $100/day. Let’s say you need at least $50 to make it each day, and on the second day you buy $80 tickets.  Since that leaves you only $20 for that day, the rest of that $50 will have to come from other days.  Thus, $30 / 5 = $6 will be taken from the remaining days of your trip, leaving you with $94 per remaining day in your budget.

Each expense should give you a basic idea of what it’s for, should be for an amount, and should tell you when it was made.  This means a Trip object should have:

• A date (mm/dd/yy HH:MM)
• A cost
• An (optional) description (ie food, gas, tickets)

Following, the app should read the user’s mind.  The easiest way to do that is to separate every screen into an activity, and have a screen leading to another call that activity.  This way the app can be navigated using the Android back button, which essentially calls the finish() command in code.  Whatever the user accessed last will be the first thing they see when they fire this baby up.

The slightly harder decision is how it should look, and how it should flow.  I mapped these out the old-fashioned way:

Apologies on the quality, but my house is almost always lit like a Tim Burton movie.  The first are just some takes on the different screens, and the second details how activities and intents will link together the different parts.  There will be a main screen, a Trip View screen, A CalendarView screen that’ll allow you an overview of your finances, and maybe some settings/other stuff.  Not included are the Activities that will run the non-UI stuff, namely the DatabaseConnector which will abstract out the SQLite calls needed to get the data.  It’ll be some serious CRUD (ha ha). The other piece will be the Trip class that’ll manage the state of your trip and do the calculations necessary to make everything work.  Each Activity will be responsible for creating the listeners that will glue the back-end to the front-end, and things are starting to look pretty complete.

From here I’ll move on to coding (Finally!).  Check back soon to see the finished product.

This is part 2 of How to Build an Android App In A Week.

I’ve spent a little bit of time going through the Android tutorials, dismantled some sample apps and pored over the pieces, and time in the very complete Android documentation.  I thought setting up would be a little harder, but it’s really following instructions.  While the SDK downloaded/installed/updated, I decided on Eclipse as my IDE and set about installing ADT, which went flawlessly.  After some time when the SDK finished downloading all the components, I set up an Android Virtual Device (AVD) with some default settings.  The only modification I made was choosing Android 2.1 as the OS, under the assumption that most current phones will be compatible with it. I hope this means I didn’t lose out on any cool new features ;_; .

I’ll give you a brief and possibly flawed introduction to the moving parts of Android.  This assumes you are familiar with programming and have at least read through some of the Android documentation, but are confused by how the parts are supposed to make an app.  If that’s you, read on!

Activities

Apps are made up of pieces each called an Activity.  An activity can be anything, something shown to the screen, a service in the background, or any combination thereof.  I find Activities easiest to think about as anything with a discrete entry and exit point.  The best way to separate your app into activities is to find logical separations of logic, and divide each into an Activity. When your app state changes, such as pausing, ending, etc, a Bundle of the data the application was holding, such as values of text fields etc. can be stored, and each Activity can set how they want to react in different situations (with the methods onCreate(Bundle state), OnPause(…) etc.). Modularity is remarkably sophisticated, allowing you very fine-grained control of what your app will do in a variety of situations.

Intents

Intents are somewhat like messages in GUI frameworks  Basically, Intents are used to pass information between Activities.  Intents get a little more confusing because intents don’t need to explicitly name their destination, but instead Activities can use intent filters to signify which intents they respond to (think Slots and Signals in Qt) .  Using Intents in this way, you can call the Android dialer and insert a phone number for the user to call, or send an email without having to specifically specify the app. Android application shortcuts use these by calling an Intent in the form of com.your.app.LAUNCHER to start it, so they are very useful.  Intent filters are normally specified in the Android Manifest.  More on that below.

Bundles

A bundle is a key/value store that is used to pass information, store information, and otherwise persist it. For the most part, these are any “primitive” data-type, such as strings, numbers and some other errata.  I didn’t end up using this much, preferring to offload state data to SharedPreferences and keep user data in an SQLite database.  SharedPreferences  is misleadingly for far more than just app preferences, and acts much like a named bundle that can be shared amongst all activities if its name is known. For my simple purposes, I found it to be more than sufficient.

UI

UI elements are pretty straight-forward if you’ve ever done GUI development before.  If you haven’t I heartily recommend you familiarize yourself with some concepts of GUI development, such as layout, separating structure and presentation, listeners, message-passing and call-backs.  If you’ve done lots of HTML/CSS/JS front-end stuff, you’ll be okay.  The only thing I had to remember is that every element is called a View.  LinearLayout is a view.  Button is a View.  TextView, EditText, and . . . You get the point.

Other parts of an App

These other parts aren’t code, but allow you to specify all that good structure stuff in XML.  They are:

• AndroidManifest.xml – This stores your application information, specifying its name, icon, entry point, intents each Activity responds to, and Activities available.  After I add an activity, I frequently forget to add it here.  Learn from me and start by adding each activity through the interface here.  If you’d like to communicate within your app using intents, specify intents each activity will react to using intent filters.
• strings.xml – This is where you can store values for use later in your app.  Like a green and want to use it elsewhere?  Include it in your code in a reusable, DRY way by calling the value from strings.xml.  Strings is used for far more than just strings, allowing you to categorize key-value pairs into almost anything.  Some I’ve used are colors, dimensions, and drawables.  I’m sure I’m missing a lot of extra possibility here.
• R.java – I didn’t include this in code, because you should never edit this.  R.java is an automatically-generated file that allows you to link to resources in your project, such as layouts, Views, and resources you define in strings.xml.  R.java is your God.  Every activity will almost always start with setContentView(R.layout.yourlayout);.

Got it?  Did I miss anything.  Next up, Planning the app.

I’ve been wanting to write an android app for awhile, but every time I start, something seems to get in the way. I start, but I don’t have an android. I think of a cool idea, but it’d be better as a web app. I have everything in place, but I’m holding some particular grievance against Java that I just can’t get over.

Well, the time for excuses has come to an end. I will write an Android app in one week. From plans to specs to implementation to release, I will release it or die trying.  Over the period, I’ll be giving my thoughts and at the end, presenting the finished product.  Here’s more or less what I’ll report on:

• Introduction to Android SDK/Java – This’ll be a list of what I needed to do to get set up, some initial impressions of both Android and Java, and will serve as a small-scale introduction to Android
• App planning – Planning of the UI, figuring out the pieces of the app and how they’ll glue together, and looking at typical use-cases
• App finish / release – Taking a look at the finished app, mapping future improvements, and examining changes between initial specs and the finished product.

This guy must think he’s good at Java

I would like to take this time to say I’m not a Java programmer. I’ve used Java, I’ve built apps in Java, I use OOP a great deal, but I’m not a Java programmer. A Java programmer is willing to spend an inordinate amount of time laying getters and setters, subclassing everything to add errant functionality, and spending quite a bit of time working around the structure of the language to.  Now, there’s a good chance I’m Doing It Wrong, but I am not one that believes embedding a listener should involve subclassing to implement an abstract method, instancing a class, and embedding it through a function call is ideal.  Feel free to rip me apart, this is in fact the internet.

Well then, you must know things about Android

I don’t  know anything about Android, and although I like to think I know some things about coding, I am by no means a battle-scarred veteran.  If anything, I’m just a guy who knows Python really well and some other C-style languages well enough to read and code in with lots of API and syntax look-ups in between.  Hopefully, I am you.  And if you’re way above that, go back to your IDE.

But why only a week?

I like to think blind panic is the best way to operate at peek efficiency.  Frankly, since I’m not a huge fan of Java and this will most likely put me far out of my comfort zone, I’ll need a little something to push me along.  Imposing a deadline will force me to always keep pushing, even when I’m feeling bleh.  Second, I want to make sure this app, being the first, is smaller-scale.  Putting a strict deadline on is a great way to prevent bloat, and focus on immediate release.  Last, it sounds great, doesn’t it? :p

What’s the plan?

More or less, here’s my attack:

• Prepare my dev environment
• Run through/examine sample applications for a basic idea
• Plan application development
• Code like a fiend
• Profit

There will be write-ups straddling the run-throughs and application development, and one at Profit.  Hope to see you there with some pearls of wisdom.

HTML5 is cool.  Very cool.

I’ve been farting around with javascript, pretending it’s a real language that can do real things.  Turns out that as long as I don’t get caught up in tearing my hair out over the ugly stuff, I don’t even have to pretend.  I don’t have to pretend so hard, I started building a game engine (modern browser required):

If anyone’s interested, I’ll post a write-up on how I’m building it, and I’d welcome input into making it better. I know the debug text is jacked up in the iframe above, but I need to dig into some actual work and I know if I start with just a couple edits, I’ll wake from a daze at 2am with tons of code, offshoot projects, and tests.

Closures are a real pain, but object-oriented javascript makes the language manageable enough to build real programs. Even Grooveshark, ever the flash juggernaut that it is, appears to be migrating away from Flash and into HTML5/JS. This might be because of their ban from Apple’s app store, which removes a massive section of the market for them. Moving to HTML5 would destroy Apple’s monopoly on iOS devices (though I doubt it’d destroy Apple’s majority). Music is still played through Flash, as sound in HTML5 still isn’t that great.  Even playing WAV files kills processor.  I really wanted sound in this demo for you, but sound turns it to crap real fast.

One thing I’ve learned is optimizing loops (since full-screen on my computer, the hypnotoad demo pulls like 2000 objects). While loops in javascript are much faster than for loops whether or not the lookup element is tied to the DOM. For example:

for (var i=0; i<this.items.length; i++) {…} performs a lookup for this.items.length every iteration. Much better would be:
var i=this.items.length; while (i–) {…}

Or to keep the for loop and possible further optimization for the (possible) special !=0 case:
for (var i=this.items.length; i!=0; i–) {…}

Sorry for the above, I clearly need syntax highlighting and a readable font. Next update, perhaps.

You’d think the compiler would optimize this and you wouldn’t have to worry about it, but it certainly doesn’t in Chrome (8.0.552.224). In arrays of 2000 length, the speed-up in my engine is something like 5-10%. Oh javascript, you rascal.

Optimizing the number of entities on screen between different mobile devices, notebooks and desktops with dynamic programming will be something I’ll be looking into as well. A lot of stuff I have in the engine just won’t fly on mobiles, and providing a way to benchmark and scale is very attractive to targeting all possible devices.

Web apps are the future.

We write online, prepare our taxes online, communicate online, work online–We live online.  Data means nothing unless its accessible to you 24/7 in our entitled web paradigm of interconnectedness.  Desktop applications will remain for a while yet, while broadband pipes force internet goodness to an anemic trickle, but the last mile won’t remain a bottleneck forever.  Soon the browser will be the operating system.

Web technologies are stepping up.  HTML, CSS, and Javascript will remain cornerstones of how we interact with the web, but the changes in CSS3 and HTML5 are startling.  Why, here’s a simple snake game I made in 4 hours, without knowing a single thing about javascript.  There’s almost no reason to use Flash, and certainly not for much longer.

So I will be adding HTML5/CSS3/Javascript to my stables.  By no means will I be shirking powerful lower-level languages like C, though I will most likely continue using Python in my server-side applications.  And API’s everywhere.  API’s out the wazoo.

I don’t think any of these ideas come as a surprise to anyone who cares about these things, but I am damned excited about it, and I just had to share.

Charlie Stross has a thought-provoking piece on network security entitled Where We Went Wrong.

What would I propose?  First, give “security specialists” a thorough background in usability and design.  I don’t think antivirus software should run consume all available process I/O with priority and manage to have hard-to-use interfaces that are unresponsive when scans are run.  That doesn’t strike me as a valuable service, but more of a gigantic pain in the butt.  Being unable to encrypt low-level protocol traffic and certificates of trust are secondary to expert systems that reinforce best practices.

Second, realize that until these improve, hacking will be profitable.  As long as hacking is profitable, it will be a concern.  There are a great deal of idealists amongst security professionals who are quick to denounce other companies acting in their self interest.  I wonder how those professionals would feel about working toward eliminating their job.

I hit upon an excellent article just now on Dot Mac:

Good programmers spend much of the other 90% thinking, researching, and experimenting to find the best design. Bad programmers spend much of that 90% debugging code by randomly making changes and seeing if they work.

Very true.  I suspect most of my time goes into research and learning.  After all, what makes a programmer valuable is what he (or she) knows.  When I pick up a job creating a website or touching up something, I may ask for a few hundred dollars for what seems like a few hours work to a client, but what led to such an elegant solution was years of research, diligent study, and experience.