Monday, 20 October 2014

Smash Info - Android edition

Part one of Smash Info's development blog can be found here.

So after submitting the Windows Phone version, I had a few hours break before getting to work on the Android version. I had actually discovered a crash in the WP submission version but decided that could wait for the first update since its only a minor inconvenience. As always, Eclipse had issues loading in the Android packages so I had to fix that first. Rather than opting for my own graphical style, I decided to use the system's predefined style which meant I'd have to use layouts *shudders*.

I wanted it to look as close to the WP8 version as possible so whilst the underlying code may differ, the look would have to be the same. The first thing I did was battle with the layouts to get the front page laid out correctly. Then I created blank versions of every subsequent page. One difference almost immediately is although the Android version did have a Wii specific menu page created, it doesn't use it and works out the button presses via the initial message sent to the page's start-up. Theoretically the WP version could work the same way, I just didn't want to implement it at the time.

Whilst I've used Java and Android a lot in the past, I've never created a pop-up message box before. Have I ever needed to present something to the user I've just used Toasts, usually because the message I'm sending is quite short. As the message box used in Smash Info displays 3 paragraphs, a Toast isn't going to cut it here. Displaying the message box wasn't too difficult. Slightly longer than in C#, but not a lot of hassle.

I've previously grabbed data from XMLs to use as data in the app in Fletchbook but it's been a while. To give myself a refresher, I looked at the code for that and then discovered that the XML stuff seemed to be missing from the source code we handed in. Then I realised I was looking at code from several months before submission (I was beginning to think we'd actually handed it in without the Dropbox integration present, which wouldn't surprise me considering how last minute it was). After digging out the right code, I got scared and went to bed.

Once I'd implemented the file reading code, it wasn't working properly. I ended up putting Log.i(); after each line to trace where exactly my code was broken and it eventually boiled down to the creation of an OuputStream. In my catch() code I had a Log.i() line telling me my try code had failed, but since I always remove the e.printStackTrace() bit, when I finally put it in I shook my head and walked away.

Getting these to display took way longer than it should.
The OutputStream could not be created because of a Permission Error. I had not defined any permissions in the AndroidManifest, mainly because I did not intend to use them, and that what was causing the read error. After fixing that one line, everything started to move smoothly for about 5 minutes when I uncovered my next stumbling block.

On the WP8 version, when each button is created its OnClick method works out what data it needs to send to the next page based on the text in the button. When attempting to do so on Android, it does that but the data will always remain as the last entry on the list. Unless you pass the text on the button without passing the button. It's weird. I don't understand why it works now when parsing just the text nor why it didn't when parsing the button.

My next issue was getting the images for each item to display. It's weird that even though I've worked with Android a lot more, I get so much more confused by it. Just like the reading from file code, I spent a bit of time refining the code I had written to work out the solution. The stack trace kept giving a NullPointer error so I assumed for some reason the file wasn't loading correctly (weirdly the text wouldn't show up properly depending on whether I put a ".png" at the end of the file name). And just like the file code, I'd made a rookie mistake. The code that populates the text and image boxes is called before grabbing the image box from the view. And with that fixed, I was done.
This also took way longer than it should have.
As always with Android testing I have my old Samsung phone running 2.2 (my low end device), and my Nexus 7 running 4.4 (my high end device). It's almost impossible to test it on every device but my logic is if it looks OK on both my phone and my tablet, it's going to look OK on pretty much every device in-between.

It would be nice to round off this project with an iOS version but I can't justify forking out on an iOS device that works (my iPod's button doesn't work; you had one job Apple), and the Mac to develop it on. That said I saw the price of a Mac Mini the other day and it was quite tempting (there is still the issue of getting a working iOS device). If anybody is interested in working with me to get an iOS version running then feel free to contact me (details on my Contacts page).

The app is available on Google Play and the Windows Phone stores now. Updates for both will become available when the Wii U version of Super Smash Bros. is released later this year.