Category Archives: coding

Your Broadsheet.ie Android app has arrived

Finally, more than two and a half years after my iOS version was released I’ve built an Android app for Broadsheet.ie and it’s available now on the Google Play store.

The app doesn’t quite have feature parity with the iOS version but is close enough that it warrants release (especially considering the clamouring for it from the readers). I will be actively developing it over the summer in step with some updates to the iOS app.

The Android fragmentation issue means I’ve not been able to test it on all platforms, but I’ve made an effort to ensure it works on the top 10 devices that access the website. Hopefully the app won’t look too bad outside of these.

Think you can do better?

As with the iOS version of the app, the code is available on GitHub under the MIT license. I do this not in the hope that someone will come along and fix bugs or improve it but in case someone else finds it useful and wants to use it.

I would, of course, be delighted if someone actually did create a pull request…

And now over to you

The Android using section of our readers have been very vocal about wanting an app. When presented with evidence of lower engagement on the site from Android the lack of an app has been blamed (an opinion which I don’t subscribe too – it seems more like Android users don’t really use their devices compared to iOS).

The only way developers are going to take Android seriously is if people actually use their phones and download apps. So grab the app today and make this developer a happy man!

Eclipse, ADT, Maven, m2e, Android Connector setup

2 Replies

I’m looking at some Android development at the moment in work after being immersed in iOS development for the last few years. Switching tools always has a bit of a learning curve and this post documents what’ve setup so far. I’ve had a few false starts so this might come in useful to someone else.

Since pretty much everything I do these days app wise involved consuming some sort of REST API, I went looking for a library to handle that end of things. I came across Robospice which at first glance fits the bill for what I want. It uses Maven for project and dependency management.

As I’ve not really used Java I’ve never used Maven in anger and had some difficult in setting it up properly. While there are instructions out there, they all assume some working knowledge of how Eclipse, Maven or the ADT works so not ideal for a complete beginner. There was a lot of googling and reading Stack Overflow before it finally all worked.

Here’s the steps I followed to get it running on my iMac:

Download the Android SDK as the ADT bundle and install
Set the environment variable ANDROID_HOME to point to the sdk directory
Run ‘android update sdk –no-ui –all –force’ (android is under tools in the sdk folder. Also, this can take a while as it downloads everything)
Open ADT and install the Marketplace Client via ‘Install new software…’ under ’Help’
Install Eclipse Plug-in Development Environment via ‘Install new software…’ under ’Help’
Install M2E Plugin via ‘Install new software…’ under ‘Help’ using the URL http://download.eclipse.org/technology/m2e/releases
Install Maven 3 if you have an older version (or none) on your system
Install Egit from the Eclipse Marketplace
Install Android Configurator from the Eclipse Marketplace (search for ‘android m2e’)

After all the restarts, you should be now at a stage where you can import Maven projects.

There’s a couple of more steps before you’re able to create a Maven project:

Start creating a new Maven Project
In ‘Select an Archetype’, click on ‘Add Archetype…’
Set ‘Archetype Group Id’ to ‘de.akquinet.android.archetypes’
Set ‘Archetype Artifact Id’ to ‘android-quickstart’
Set ‘Archetype Version’ to ’1.0.8′

You can then continue on creating your project. Once it’s created you may see the error “Project ‘skillpages-android’ is missing required source folder: ‘src/test/java’ “. This is a known issue and here’s two solutions to this:

Create the directory and refresh the project
Update the Android Configurator from the URL http://rgladwell.github.com/m2e-android/updates/master/

I will note that after I updated the plugin, it broke creating new projects for me. But I’m not sure if that was something I did or an issue with it. I ended up removing and reinstalling it.

Hopefully this will help someone else bootstrap themselves into Android development and not just left fruitlessly searching.

Slides from the Broadsheet App talk for Xcake:labs

1 Reply

Above are the slides to my talk at Xcake:labs about the latest version of the Broadsheet app.

And to be nice, all the URLs mentioned in the slides:

App download stats

JSON API plugin

Broadsheet Fork of JSON API

KMWordPress on GitHub

Broadsheet.ie iPhone App 2.0

1 Reply

For the last few months I’ve been picking away at a new Broadsheet app for the iPhone. It’s finally been released to world so it’s time to talk about it and some of the changes.

Raison D’être

The original version of the app was released in January 2011 and bar some minor bug fixes released in March 2011, it has gotten little attention since then. While the app has been well received, there’s various bugs with commenting, sharing, post rendering and loading new posts.

The app also looks very tired and old compared to its peers so a bit of a more modern look wouldn’t go astray never mind the fact that none of the image assets were updated for retina displays.

What’s New

Straight off, for those on an iPhone 5, the app is no longer letterboxed.

There’s a new layout which disposes of the need for a tab bar by moving the information and tip tabs into the nav bar and eliminating of the gallery and video tabs. The purpose gallery tab has disappeared as Broadsheet now posts galleries as images inline rather than using a javascript gallery.

The post archive is now searchable via a search bar which is hidden at the top of the post list. While the search is powered by the not-great standard WordPress search, it does open up more content to the user.

Down on the bottom right there’s a fullscreen button. This hides the status and navigation bars giving you an extra 64 pixels of space to gaze lovingly on the content. When in fullscreen mode, there’s a little back arrow at the bottom left to help you navigate between screens.

Tapping an image in a post now brings you to that image in a gallery of all images associated with the post. You can now easily zoom the image and swipe between the other images associated with the post.

There’s no need to return to the post list screen to navigate between posts. Dragging the screen down will load the next post while dragging up will load the previous. This turns into an infinite scroll for posts as long as there are more posts to view. The post list screen will also be updated with the extra posts.

The comment view is now threaded as well as rendering people’s avatars (which are generated from Gravatar) properly. Now all we have to do is get people to sign up for their own avatar. Comments can also be replied to directly as well as creating new posts.

Touch me

A big change from the original app is the use of gestures through out for navigation. Swiping left and right brings you between the post list, a post and the post comments. This allows for quick and easy navigation.

Swiping left on a comment allows you to reply directly to it, providing a secondary access method to the reply button.

On a post screen, the available controls are revealed with a long touch, putting the buttons just above your finger tip. These allow you to view comments, make a comment and share the post.

A Bit of Help

Gestures and hidden navigation is all well and good but it can be hard for users to discover. This is easily solved with a couple of help screens which appear the first time you hit the post screen or go full screen. These very quickly show you what you can do using some great gesture icons from Mobile Tuxedo.

Down The Line

There has been a consistent call for an iPad version of the app. I have started on making the app universal (i.e. works on both iPhone and iPad from the same download) but for the initial release I decided that getting the iPhone version right was more important. Hopefully I’ll complete the iPad changes over the next few months and release that as an update.

Other Platforms

An Android and Windows Mobile version of the app are in development and should be released soon.

You can download the app from the Apple App Store and if you have the previous app already installed you should be able to update.

Yet Another Searchable Property Price Register

Leave a reply

Last Sunday, the Residential Property Price Register was launched. Since I’m keeping an eye out for something to buy, I was fascinated by the details it contained. But the search options were limited and there was no map. However, the data was downloadable as a trio of CSV files. So Yet Another Searchable Property Price Register was born.

I dumped all three files into a MySQL db, slapped a PHP script in front of it for searching and another to geocode the addresses and used Twitter bootstrap to give it a bit of spit and polish. All in all it was a few hours work and another few hours to get the data geocoded. It really leads me to ask what problems were encountered that resulted in it taking two years for the data to appear online.

If you want to have a look at the code or raw data, you can visit the repo on GitHub. You’ll see a friend of mine, Mike McHugh has already helped make my rough version all the better. I’ve included the database so people can submit improvements to the data.

Of course, it was such a good idea other people had it as well. They all put their own search interface onto the data and some did a few more interesting things. The ones I’ve found so far are:

The head of the Property Services Regulatory Authority, Tom Lynch is quoted in an article in the Sunday Times (Home Truths, page 10 on 7/10/2012 – behind a paywall so I’m not bothering to link) as saying the don’t have additional information like square footage, number of bedrooms and other details that would truly make the information useful. Yet Daft.ie’s version does just that using the data they have on hand. Surely an interface could have been built for registering the houses that asked for these details (as well as actually validating the data and avoiding clangers like ‘Gawlay‘) when submitting for stamp duty.

It also seems odd that the official version didn’t consider mapping the data. Even if they didn’t ask for the location when gather the data, services like Google’s Geocoding API (which I used) are available. While not perfect, it gives reasonable results most of the time.

It’s great to have the data, but there’s a lot more information that would give context and enhance what’s there. Hopefully the criticisms and improvements made by 3rd parties will be taken on board and a much improved version will appear in the near future.

Hopefully someone will find this useful and I’ll be updating the database as more data becomes available.

Invalid IPA: The keychain-access-group in the embedded.mobileprovision and your binary don’t match.

Leave a reply

Provisioning profiles are such a delight. My latest battle with them involved getting the following error:

Invalid IPA: The keychain-access-group in the embedded.mobileprovision and your binary don’t match.

The background to the situation is this: I’d run out of devices on one of my Apple Developer accounts and needed to send out a test build to some new users. So I created a new bundle ID in my second account, re-archived the app and sent it out. The tester came back with the above error when they tried to install it.

The problem lay with me not changing the application-identifier and keychain-access-groups values in the entitlements file. These need to match the new provisioning profile values. The values for these changed because I was using a different developer account. keychain-access-groups is easy to miss as it’s folded when you open the entitlements file in Xcode.

You’ll find the correct values in your provisioning profile as well as in the App IDs page in the iOS Provisioning Portal.

Another error I hit with my second dev account was:

entitlement ‘application-identifier’ has value not permitted by a provisioning profile

This turns out to be caused by signing the IPA with the wrong identity. How did I manage that you ask? I was using my auto archive script and I’d forgotten to change what identity to use when signing. There’s two hours sleep I’ll never get back.

Previously: The executable was signed with invalid entitlements. (0xE8008016)

A Sunday Afternoon Project: KMMapList

Leave a reply

I’ve been toying with the idea of doing another version of the Pint of Plain app and one of the things I want to change is list of bars you first see when you open the app. During the week I ended up on Dribble and saw a screenshot from an app called Chow Now.
What I liked about this is that the extra detail about the restaurants is present at the bottom where’s there’s more room to breath. It’s a nice combination of the now traditional map and list views. I’m guessing that tapping a pin will make the scroll view move and swiping the scroll view highlights the pin. The details at the bottom are far more detailed than a normal call out and there’s enough room to have the phone number tapable as well as leading to a more detailed view.

Now I’m sure this will be easy to build with [REDACTED] in iOS 6, but I want something I can use now as other wise it’s an idea that would lie rotting in my brain. I also wanted to play with reusable UIViews built with Interface Builder as a test for a couple of future app ideas.

I’ve a first pass of my code in a repo on GitHub and I’ll probably be poking at it a bit more over the next few weeks. For something that I kicked about for a couple of hours today the core of it is there and I’m happy enough with the result. It’s not as pretty as the example from Dribble, but that was never going to happen with my cack handed design chops.

Functionally there but just not pretty

There’s probably quite a few improvements that could be done to the current code (apart from the obvious hard coding of the data points). It’d probably be better if the off screen views were generated just in time rather than all at once and I’ve still to figure out how it’ll handle a large number of annotations. Still, it’s a good proof of concept and worth moving along. We’ll see how it goes over the next little while.

Clickable Skin on a Website

Leave a reply

I was asked the other day how Broadsheet.ie does the horrible clickable ad skins so I may as well document it here as well. I can’t remember how I exactly figured it all out but I’m sure posts on stackoverflow.com helped as well as looking at the source of the likes of entertainment.ie to see what they did. As always, this works for me and your mileage may vary.

First we set up the css for the background image:

body {
       background-image: url(/images/some_image.jpg);
       background-attachment: fixed;
       background-repeat: no-repeat;
       background-position: center top;
       cursor: pointer;
}

#page {
       cursor: auto;
}

This pins background image to the center of the page so if the user resizes the window it doesn’t move. It does mean that a user may not see it if their browser window is narrower than the background image.

To make the pointer turn into a hand when the user is hovering over it, you need the ‘cursor: pointer;’ line. However this makes the cursor a pointer everywhere, so for the actual content of the page ‘cursor: auto;’ needs to be set so it will use the correct default when hovering over content that is not a hyperlink.

Next we need to capture clicks made on the background. This is done using some JQuery:

function recordOutboundLink(link, category, action) 
{
   _gat._getTrackerByName()._trackEvent(category, action);
   setTimeout('window.open("' + link + '")', 100);
}

jQuery(document).ready(function() {
       jQuery("body").click(function(e) {
               var target = jQuery(e.target);
               if (target.attr('id') == 'body_id')
               {
                       recordOutboundLink('http://www.karlmonaghan.com','outbound', 'karlmonaghan')
               }
       });
});

Last, but not least, we need to change the body tag:

<body id="body_id">

What the javascript in the document ready block does is capture click on the page. The id of the element clicked on is retrieved and if it was the id we’ve assigned to the body itself we call the recordOutboundLink function. This function takes 3 parameters – the URL the user should be brought to, the event category and event action. We use this function so we can record the click in Google Analytics for our own information. If you’re not interesting in the stats (but really, you should be) you can replace this line with a just a document.open call.

Personally I’m neither fond of this sort of advertising nor convienced that it’s particularly effective (although it will very effectively annoy your users) but if someone is willing to hand over a ball of money for it so be it.

Auto-Versioning and Auto-uploading to TestFlight/HockeyApp When Archiving in Xcode

Leave a reply

I’ve been playing with TestFlight this week with some of my apps. The main aim of my experimentation was to have the version numbers of my apps incremented and the IPA automatically uploaded when I archive a project.

There’s a lot of posts already on various parts of the process, but I’d thought I’d document the whole process I went through as there were a few tweaks to be made on the snippets of code I found.

I’ve projects both in local SVN repos and on GitHub so I need to be able to create version numbers from both. Another wrinkle is that I sometimes use HockeyApp as well, so I decided I may as well be prepared for those occasions and include it in the script.

The first step was to increment the version number. A post from Stackoverflow gave me the starting point and with a few minor tweaks I ended up with this:

This script needs to be run before Xcode does a build. To do this, it should be added as a ‘Pre-action’ to the build function. Edit you scheme, click the down arrow beside ‘Build’, select ‘Pre-actions’ and then on the + at the bottom left of the box on the right. You’ll be given two options and you’ll want to select ‘New Run Script Action’. Select your target in the drop down beside ‘Provide build settings from’ and paste the script from above into the box below that.

Now when you archive your project the Bundle Version will be updated.

For git, we just adjust the REV line:

We could have used something like ‘git describe –dirty’ here instead, which would produce something like 1.2.1-1-ge03a85c-dirty as the version number. But when you submit the app to Apple if the version number isn’t all digits your app will fail validation so you’ll have to manually change it beforehand. Since this is something I’m prone to forget so I’d rather just have the digits.

After the version number has been updated, Xcode creates the archive and then we need to create the IPA upload it. This is done by adding a script to the ‘Post-actions’ of the ‘Archive’ action.

Justin Miller’s post ‘Automating Development Uploads to TestFlight from Xcode‘ got me most of the way creating and uploading the IPA to TestFlight. There’s been a few forks of the original gist, and I ended up extending one by c0diq to include uploading to HockeyApp. I also added a couple of extra flags to make the script less chatty when you know you want to upload the IPA on archive and when you know the code signing identity to always use.

Something to note is that HockeyApp is less tolerant of duplicate bundle versions than TestFlight so if you’ve not made any commits since the previous version, the upload will fail. You’ll be able to see the error returned by HockeyApp in the error dialog and more details in the log.

That’s pretty much it. It seems to be working fine at the moment but I’m sure I’ll end up with a few more refinements as time goes on.

A Sunday afternoon project: Providing App Store stats via JSON

25 Replies

Last month Apple announced their auto-ingest tool for fetching the download and update statistics for apps. The tool downloads the stats for a particular day or week as a gzipped CSV file that you can then process yourself. This is far nicer than having to try and scrape the numbers from the iTunes Connect page although the daily numbers are still restricted by a two week limit and the weekly by 13 weeks. Hopefully in the future you’ll be able to retrieve further into the past (assuming the data still exists).

I’d a bit of free time this weekend and decided to have a poke at this and see if I could grab the data and present it in a easily consumed format (i.e. JSON). Another reason for looking at this is because I have two iPhone Developer accounts and it’s be nice to see the data from both as one graph rather than having to log in and out.

To that end I wrote a couple of lumps of PHP to ingest and process the stats which is available on GitHub (https://github.com/kmonaghan/itunes-connect-auto-ingest). There’s a couple of small steps to get it all to work.

First, create a database (or just use an existing one) and create the table in schema.sql.

Next, edit boot.php. Here, you need to put in your database details and the details for each iTunes Connect account you have. To do this you need to put in an array with the following key pairs:

array('username' => 'iTunes Connect username',
'password' => 'iTunes Connect password',
'vndnumber' => 'VND number',
),

The username and password are the details you use to log into iTunes Connect. You’ll find the VND number if you log into iTunes Connect and go into ‘Sales and Trends’. It’s the number beside your name at the top left of the screen.

You can have as many of these accounts as you want and the ingest script will check each one.

Now all the details have been set up, you can ingest the data from Apple. This is done by simply running ingest.php. If it’s the first time the script has been run, it will look back 14 days. Otherwise, it will look in the database for the last successful day there was an import and attempt to import all days since then. After your first import, you should create a cronjob to run this script once a day to capture the latest stats. If the downloaded tar files are 0 bytes, check your login details and VND number.

Once all the data is in the db, we can view it via daily.php which outputs the results as JSON. This will by default output the total number of units downloaded for all apps in the last month. It can take four parameters:

apple_identifier: A particular app identifier.
product_type_identifier: This can be 1 (default) which is downloads or 7 which is updates.
from: The date to get the stats from. Expected as dd/mm/yyyy. Defaults to 32 days ago.
to: The date to get the stats to. Expected as dd/mm/yyyy. Defaults to yesterday.

And that’s that! There’s some Javascript in stats.html which consumes the JSON and uses the Google Chart Tools to display the results. An example of some live data using my own apps is available here.

This is very much a works-for-me lump of code, so it may not do exactly what you want but it should be easily extendable to provide exactly what you want. It will certainly not cover every error condition. I’ll probably add bits and pieces to this as I think of a stat I want to visualise or I come across a ~~bug~~ unexpected feature.

Something I might consider looking at in the future is writing a clone of the iTC Mobile app that utilises the saved data. It’d be a nice little project to try out Core Plot.