Monday, December 20, 2010

Handling onClick in ListView with embedded WebViews

Oh boy, dear readers, I have something relatively good to show off!  It's a bit of a hack, but it's something we fought with for a very, very long time that hasn't had a solution posted.

Firstly, like a lot of other people, we decided we wanted to override our ListViewAdapter to make a custom layout.  This in itself is not difficult, and there are many, many good tutorials out there on the internet.  We followed this one and the supplementary article linked within.  For anyone looking to start doing so, check it out. It's really the best way to start getting the best out of the provided layouts.

For our purposes and using what we had available, we needed to use an ASP file to generate the thumbnail for our textbook listing.  We found out upon trying to load it directly to an ImageView that it is actually returning an entire HTML block.  When attempting to strip the image URL from that block, we found out that it was simply the same URL we'd just visited.  Without much recourse, and no way to get at the data ourselves (3rd party systems, hurray!) we resolved to use a WebView and cut our losses.

When you use a focusable/clickable object inside a custom ListView layout, you immediately run into a problem: they steal all input from the ListView's native onClick events.  This is overidden easily by setting the focusable="true" attribute to focusable="false".  Same goes for clickable="true".  This works for everything except a WebView.  Because WebViews are more complicated and listen for a lot more types of events and more inherent functionality, a simple attribute change won't do anything.  It essentially leaves your entire ListView item dead in the water.

The solution?  Handle the click event in the WebView.

This is a hack, as I've said.  This does not restore the functionality to the parent ListView item.  As of this posting, I haven't figured that much out.  This will, however, handle the click when it happens to the WebView.  You could replace your entire ListView item with a single, formatted WebView and this would work swimmingly, but for our purposes, that's more trouble than it's worth.

Onto the code!


Wednesday, December 15, 2010

Extra This-and-That

Been working on little things for the app over the last couple of days.  Mostly filler stuff to make it more robust, nothing especially difficult.  Here's a run-down of what I've done and any additional info on it:


  • Added Store Info tab with photos of each campus, the phone number and address.  Need to do screen resolution handling, but that's the same for the whole app, so not worth a separate bulletpoint.
    • Making the phone number and address clickable was extremely easy.  In the XML for each TextView, just add android:autoLink="phone" for phone numbers and  android:autoLink="map" for addresses.  The former puts the number into the Dialer and allows you to just press send, the other gives you the option of opening the address in Maps or the Navigator.  Handy!
  • Added a Send Feedback function with user-entered name, e-mail address and comments.  It generates the subject on its own based on a Spinner for type of feedback and the supplied name and e-mail address.  The comments have an appended line for whether or not the user clicked a CheckBox requesting a response.
    • If you try to use Intent.EXTRA_EMAIL with new String("jldomagala@aacc.edu"), the To portion of the generated e-mail will be suspiciously blank.  For some reason it accepts this without compiler errors, but unless you style it new String[]{"jldomagala@aacc.edu"}, you won't get what you're looking for, or expect.
    • Not programmatical, but apparently my work e-mail address filters out anything with curse words in it.  Guess putting in a comment asking 'why does this shitty app not work right?' was a bit too much for it, haha!
  • Found a bug in the Hours of Operation calendar with displaying the dates in the proper cells.
    • Each month is padded by empty, greyed-out cells that ensure that all the dates fall on the proper day of the week.  My test month (December 2010) was displaying properly by pure luck due to the improper calculations.
      • Beginning of the month padding went from for
        (int i = 0; i < (Calendar.SATURDAY - date.get(Calendar.DAY_OF_WEEK)); i++)
         to
        for (int i = 0; i < (date.get(Calendar.DAY_OF_WEEK) - 1); i++)
      • End of the month padding went from
        for (int i = 0; i < (Calendar.SATURDAY - date.get(Calendar.DAY_OF_WEEK)); i++)
         to 
        for (int i = date.get(Calendar.DAY_OF_WEEK); i < Calendar.SATURDAY; i++)
So, all in all a relatively productive day.  More nuances and bug-fixing tomorrow.

Monday, December 13, 2010

Demo Day Recap

Ah, things are finally calming down, readers!  With our first major milestone reached, now it's on to polishing and bug-tracking on the app.

My partner suggested I mention that mere hours before DD started, I not only made all the signage for the table, I also edited together a quick demo video in case something happened on the phone or we lost service and added in my hours of operation functionality, did three quick bug-fixes and got everything set up by 12.  While I think this showcases how horribly irresposible I am and that I don't do things 'the right way,' he maintains that it shows I work well under crunch and am highly resourceful.  I'll leave that up for you to decide.

I don't feel I can rightfully brag about the video.  I find it to be very crude, but it did its job when we did occasionally lose service, or the table was too crowded to allow anyone else looking at the single Droid2 that we had to play with.  It also showed off the Event functionality that I had commented out just prior, as the duplicate checking wasn't working yet and I didn't want 100+ 'Demonstration Day' events added to my calendar.  Smart thinking on my part, haha!

We did at some point lose our camera, so I do need to see what there is to be done about that.  I realized this after a particularly good set of comments, so we'll have to figure out just when it bailed on us.  No matter how full a charge you have, if your camera is running, recording raw footage for 2+ hours, it will die.  I did pull it off the tripod as soon as I noticed and charged it between demo's after that, so we do have some other good footage, just a shame.  Learning experience and all that.

I was pleasantly surprised that though our app was really primitive visually, people loved it.  No one really said it needed to be cleaned up or that it was hard to read or navigate.  That means, of course, that as long as we keep to our basic principles, we should be fine.  A definite, definite plus.

The boss' boss' boss showed up again, which was really great.  She seemed really impressed with how much we had done, I got to give her a quick demonstration and she hung around watching me interact with all the students.  Apparently everyone is very surprised at how well I interact with people.  Not all programmers are terrible introverts!  Promise!

All in all, we did really well.  My partner congratulated me and went as far as sending me a quick email afterward to say he was happy to have worked on the project and to let him know if I need any more help.  We gave out probably somewhere around 12 pizza's worth of slices to people who were filling out surveys and giving us soundbytes.

Lastly, here's the demo video we used.  No complaints, it was done in about half an hour, haha!


Tuesday, December 7, 2010

Starting Over

Hello hello again dear readers!  I do owe you quite an update, but unfortunately I haven't had to time or energy to do so adequately.  Suffice to say, I will sometime near the end of this week, as promotion for my Android app is beginning sometime between tomorrow and Wednesday.  That will feature all of our new functionality in video format, so you'll get another nice run-through of what's been going on since my last in-depth feature summary.

To tide you over until then, I'm going to drop off a base Away3D file that I recently wrote for my internship to help one of their Flash designers get into the swing of things.  It's a basic start-up file that handles some input and is ready to have objects added to it for display.  It's heavily commented and (hopefully!) logically arranged, so it's good for any beginner that wants to wade through it.  Enjoy!

Monday, November 29, 2010

Busy busy busy

Hello dear readers!  I do promise that I haven't abandoned you.  Things have just been very busy, and yet I have nothing substantial to show for myself.  I do have a video that I owe you, but at present... well, we've sort of broken our build, in a way.  We're trying to overwrite a ListView to display our textbooks with and we're having a limited amount of success with that.

My partner has been working on that bit while I've been busy hacking away at getting a functioning Calendar add-on for our little project.  So far so good, though I don't have anything working quite yet, save accessing the Calendar app and reading in all the active calendars.  Adding an Event isn't currently working, but I have a hunch it's based on my formatting of the time and date.  Once I figure out a decent way to do that, I'll be sure to share.

Wednesday, November 17, 2010

Prettier Every Day

After yesterday's brute-force parsing adventure, I set forward to-day to finish what I started... and I succeeded! I really am quite pleased with the pace that this project is going.  In roundabouts two weeks, give or take a few days, I've managed to not only figure out how to get the data I wanted but how to chop it up and display it in a format most would find agreeable.  This is where refinement comes in, different forms of display, different functionalities and all the bells and whistles associated and in excess.

So, more concisely, to-day I went through some parsing adventures, writing out my ResultHandler in a way that it would traverse the haphazardly modified HTML from yesterday.  Misadventures are as follows:

  • Not all the tags had a class attribute, which is what all of the book information had and needed to be checked against.  This rewarded me with a NullPointerException whenever I tried to check it against the tags for each part of the book info, which leads me to...
  • if (atts.getValue("class") == "book-desc") or anything similar will always return false.  Why this is, I'm not entirely sure, but thankfully changing the check around to if (atts.getValue("class").equals("book-desc")) worked perfectly.
  • Doing a book.setTitle(ch.toString()) gave me some weird garble in the title field instead of the proper title, despite the title being read in.  Doing book.setTitle(new String(ch, start, length)) with all the values passed into the character parsing function did fine.
All in all, not too bad.  I'm getting the hang of writing custom SAX handlers, for both XML and what I hesitantly call XHTML to suit my needs.  Things can still be condensed and made more elegant, but for functionality, I've got it more or less down.

Tomorrow I'll make a short video showing off our current place in the process and going over some cool features.  For now, I'm happy with the progress.  I'm getting more confident with my skills as both a Java programmer and as an Android developer, and really, that's all I could ask of this project.  I'm also happy with  how quickly things have gotten up and running, despite all of the setbacks and the general lack of knowledge I started with.

Teaser screencap!


Tuesday, November 16, 2010

Hack and Slash

Hello hello dear readers!  Sorry that I left you for a few days there, things stalled a little at the end of last week with my projects and I didn't have too much to say for myself.

To-day though there is good news!  After running into some snags with reformatting the data given to me in the last call from my Section Spinner, I've set out to parse it rather brute-force and get what I want from it.  The HTML snippet returned is a relatively well formatted piece, but does have some quirks.  Right now I'm hacking and slashing my way through it with a standard SAX parser.

For the record, I did try to use TagSoup, but kept getting hung up on the same errors that I did with the normal SAX parser.  I can only surmise that I'm doing it wrong, but as for doing it right... well, there's nothing good on the internet or concise documentation to provide that easily, so I'm just calling it off for now.  Ha!  If I do ever revisit it and/or get it working, I'll toss some code up to help any other wayward travellers.

During a brief test, it looks like I've managed to fully traverse the document!  The following had to be done:

  • Due to XML not liking there to be more than one top-level element, I had to take the string I read the HTML into and surround it with <div></div> tags.  That made it so that everything was read and not just the first set of top-level items.
  • Second was to do a replace on &nbsp; since XML will throw exceptions when it sees them.
  • Next in the series of replace calls, all / > had to become /> as apparently that white space will make SAX ragequit without warning.  Good to know!
  • Speaking of same-line closing tags, there was one unclosed tag that needed a special replace written just for it.  For HTML from and untamed source, just having one was pretty ace.
  • Another thing SAX doesn't like are 'attributes' without values attached to them.  In my case, the <option selected value="..."> really made it mad.  Add another replace for "selected " to "".
  • Last but not least, I had to get rid of every ampersand.  That was the one 'given' for all this alteration, haha.
So, not exactly an elegant series of solutions, but functional ones.  I've only tested one path, so I'll have to make sure it's robust enough to stand on its feet with just these changes and then write the actual custom parser for the book results.  That is, unfortunately, going to be a bit of a brute-force mess too.  C'est la vie, I guess.  We'll worry about making everything better once we are functional.

I'm getting clearance this week to make an XML repository for all my currently hardcoded values to be dumped.  I'm pretty stoked about this, if only because dynamic is key.  If and when I orphan this app, it needs to be able to stay on top of things, and if they don't have someone to change around hardcoded values... well, they shouldn't need to.  So!  That's a definite plus, and what I need for the next branch of functionality to program.

I also have a partner on my project now, who is a pretty cool guy.  He's a veteran programmer with 12+ years of experience with web dev and no experience on the Android.  We're going to be putting our heads together on this as best we can, probably starting next week.  I don't know that he was entirely necessary, but the more the merrier, as they say!

So there's your update for the day!  I'll try to stay more on top of things, lovely readers!  Don't want to leave you hanging!

Thursday, November 11, 2010

Review: DroidDraw

I'm going to be doing a quick review of a program I stumbled upon to help with Android dev to-day.  It's called DroidDraw and is a free standalone program that provides a little formatting guidance for your layout/main.xml needs.  I'm going to be messing around with how I do these so bear with me.

For those who want to try it out, there is a web-based version on their website.  My review is for the standalone program.

Link: http://www.droiddraw.org/

The Breakdown

Performance
Score 7/10

Overall, the program is lightweight and responds in a timely fashion to input, when it decides to respond. Unfortunately, some of the things you think, and sometimes know, it should be doing aren't exactly what it does. It also has this curious way of emptying properties (specifically the ones regarding colour) and returning them to default.
Ease of Use
Score 5/10

The GUI is nothing to write home about, but it's self-explanatory enough that the lack of refinement can be easily forgiven. Everything is separated into tabs, buttons are clearly labelled, all of the menus are properly grouped. There is a nice drag-and-drop widget functionality, but when trying to get something into a layout you've put down, all bets are off. Also of note, putting things in a RelativeLayout is really best refine by hand. I'd like to see things tidied up a bit, especially in the widgets tab, and the WebView is one thing I noticed was missing entirely. There's also a good bit of functionality missing when loading in resources, barring drawables.

Error Handling
Score 8/10


I didn't give it a perfect score, even though I didn't have anything outright error on me and the program didn't crash at any point. The reason for this is that I have a gut feeling there's a lot of Exceptions being thrown that aren't necessarily being announced. That, or they have buttons that don't do anything. The sizing catches in the properties also have this funny habit of telling you integers must end in px if you don't enter in a proper format string, even if you didn't write any numbers.

Documentation
Score 8/10


This is where things get interesting. On the DroidDraw website, there are some tutorials, which are linked to from the program's help menu. With the exception of the 3rd party tutorial, they are very well done and offer some insight as to why DroidDraw is a little uninspiring visually. The screencaps used in the tutorials are from a Mac, and boy are they flash. I'm a little jealous! That note aside, they do have a rather nice list of views that they support with screencaps of how they appear when used. Their 'About' choice is nothing but their logo and their support information is in a tab rather than in the menu, but it's relatively good. Another nod toward straightforward design too.

Efficacy
Score 5/10

This score I find highly subjective. For the purposes of my use, it did pretty well. I couldn't figure out what I was doing wrong by hand, what was stopping things from compiling, and how to go about fixing all of that. I wasn't looking for it to do more than that. I wanted a guideline and a reference and it gave me that. For someone who wants to use it to do a full design? Probably not a good choice. I have to note again that it doesn't have an exhaustive list of options, so there is a good bit of previous knowledge required if you want something that isn't included. You're on your own for those.

Value for Money
Score 8/10

I naturally didn't pay for it, so maybe it should be a 10/10 score, but I do feel that it isn't quite a refined product, so I have to bump it down a little on principal. For a freeware, it's serviceable enough, so I have to be satisfied.

Overall
Score 7/10

I did a lot of complaining, but really, the program did what I needed. It's better used as a reference for those still new to how layout/main.xml is set up or who are getting errors loading things in and can't figure out what they're doing wrong. Did it spit out a perfectly usable layout/main.xml? Not by a long shot. I had to do a lot of editing by hand once I got it into Eclipse again. It has potential, and I would love to see it in the next update. If you do end up using this program, see if you can't throw some bug/error reports their way. Once I have time, I will be going back over it and doing so myself.

Wednesday, November 10, 2010

Proof of Concept Demo Video

Just a quick update to show off a video of the app as it stood at closing time yesterday. I actually recorded without my mic plugged in, so you'll have to enjoy it sans audio commentary. Never fear though! I did put in annotations throughout that make it easier to follow and explain why I was circling my mouse pointer here and there.





I also made a cute little Book-Droid icon to use for our dev and potentially our application proper.  Nothing fancy but I find with Android, the simplicity is key.  Good practice in Illustrator either way.




Tuesday, November 9, 2010

Proof of Concept: Obtained!

A quick update on the Android project for the bookstore.

We just hit proof of concept.  I'm really pumped for this, to say the least.  I finally navigated all the major snags and got it to pull all the XML files from the website, populate the spinners and then take the returned HTML and display it in a WebView.  Here's the rundown:

1. Had to refactor a lot of code due to a NumberFormatException that the CourseHandler class was throwing.  Turns out, the way we store our course numbers puts a lot of them in the 100k+ range, which is way too big for my shorts I was so fond of using.  It was a relatively easy fix, if not a tad tedious.  Bottom line, all shorts become ints.

2. My idea of using Vector<?> to stash all of my read-in Departments, Courses and Sections turned up an odd problem when writing out all the Spinner.onItemSelectedListener's.  It didn't crop up until the section Spinner, which only had one possible section for the particular path I'd chosen.  It wasn't ever getting inside my if-check for a valid position range.  When putting in the Spinners, I realized they auto-select the first option upon populating, so I did a quick insert before proper Vector<?>-based population of a "Selection A _____" message.  This, however, meant that the Spinner's indexes didn't line up with the Vector<?> indexes anymore.  I somehow missed this logic error until it failed to enter the if-check.  Fairly easy to fix with a <= and an index - 1 switch for referencing.

3. With a good old-fashioned BufferedReader I managed to snag the HTML bit the AJAX on the site proper was using to display the books.  Turns out WebView has the capability to take in a decent amount of HTML coding by String and to apply whatever it knows how to into its view.  Ugly, but the job got done.

So!  That means that as of 11-ish, I have proven I can snag all the data I need and can effectively show it on screen.  It went a lot quicker than I expected and truthfully, the code doesn't even need a whole lot of clean-up.  I managed to design decently on the fly, so it's nicely broken up into bite-sized functions and fairly well commented.  Some of this last minute stuff needs updating, a few commented out test blocks need to be removed, but overall, I'm happy to call our first milestone obtained.

Next on the docket is, of course, prettying up that HTML it gives me.  Not only is it poorly formatted for what I want it to look like, it doesn't have everything I would want to show to the user.  Right now, I'm thinking that I may want to simply display a number total with a button to view titles ("Search returned 3 results! [See Available Titles]").  I also want to get an HTML parser in there of some sort so that I can just grab the data I want for easier formatting on the following page.  Lastly, there is no thumbnail for the book, and I'd like to snag that (which I know how to do already, quite by accident during an experiment) and have it display next to the title.  Within that, I may have it go to a separate page with the full info, but that's further down the road.

Summary:  Proof of concept reached, finally have something to write home about.

TODO: Refine, error-check and pretty it up.  Also, make sure there are no memory leaks and that Spinners are emptying before repopulating when a Spinner further up the path is changed.

Monday, November 8, 2010

Hello hello, dear readers!

As I enter into the brave world of professional programming, I find myself constantly amazed at things I encounter and the problems I have to solve.  I've decided, in part do to a project I'm working on for the Android, to spend a little time going over some very basic day-to-day development stuff.  This may not necessarily be just for those purposes, and will likely branch out into other things as I learn, but right now that's the goal.  This is just an introductory post, going over projects I'm currently working on and so forth, but keep an eye on this and you'll (hopefully!) start seeing some pretty interesting stuff.
_______________

AACC Bookstore for Android
_______________

First things first, my major paid project right now is for the AACC Bookstore.  We're working on an application that brings the functionality of their website to the Android platform.  As a long term plan, we would like to extend our reach to iPhone, but baby steps are certainly necessary.  I've never dev'd for a phone before, so it's really a pretty amazing jump from where I've been before.  I am familiar with some of the practices, thanks to a brief stint on the Gameboy Advance in Full Sail, and have a basis in C#, which is very similar to Java, or so I've found, but it is still its own beast with its own set of problems and promise.

Things are going very smoothly and I anticipate the bulk of the starting entries to be about this project.
_______________

Away3D Crane Project
_______________


Second on my list of major projects and what occupies the rest of my time is a 3D Flash demo simulation of a crane.  It's been a lot of brute-force learning on my part in IDEs, APIs and languages in general.  Before this project I had only dappled in Flash 10, and had a minimal experience in Actionscript 3.0.  That, suffice to say, has changed.  I started with a 2D base crane, drawing up a sample cab and putting in some functionality for later use.  It was put to the side when I jumped into using Papervision3D and learned how to simulate 3D in Flash.  With time, I realized Papervision was deficient in ways I couldn't reconcile or make up for on my own, so I moved on to Away3D and haven't turned back since.

I've hit a functionality point with this project and from here out, it's actual simulation logic and fun game-dev stuff ahead.
_______________

As always, there are small side projects I'm sure to be working on, and depending on how my other learning ventures go, there may be a bit here and there that refers to them as well.

So here we go, lovely reader, onward and outward!